Jaka jest Twoja konwencja nazewnictwa dla procedur składowanych? [Zamknięte]

Widziałem różne reguły nazewnictwa procedur składowanych.

Niektórzy ludzie poprzedzają nazwę sproc słowem usp_, inni skrótem nazwy aplikacji, a jeszcze inni nazwą właściciela. Nie powinieneś używać sp_ w SQL Server, chyba że naprawdę masz to na myśli.

Niektórzy rozpoczynają nazwę proc od czasownika (Pobierz, Dodaj, Zapisz, Usuń). Inni podkreślają nazwę (nazwy) podmiotu.

W bazie danych z setkami sproców może być bardzo trudno przewijać i znaleźć odpowiedni sproc, jeśli wydaje się, że taki już istnieje. Konwencje nazewnictwa mogą ułatwić zlokalizowanie sproc.

Czy używasz konwencji nazewnictwa? Opisz to i wyjaśnij, dlaczego wolisz to od innych opcji.

Podsumowanie odpowiedzi:

• Wydaje się, że wszyscy opowiadają się za spójnością nazewnictwa, ponieważ może być ważniejsze, aby wszyscy używali tej samej konwencji nazewnictwa niż ta, która jest używana.
• Prefiksy: Podczas gdy wielu ludzi używa usp_ lub czegoś podobnego (ale rzadko sp_), wielu innych używa nazwy bazy danych lub aplikacji. Jeden sprytny DBA używa gen, rpt i tsk do odróżnienia ogólnych sprocesów CRUD od tych używanych do raportowania lub zadań.
• Czasownik + rzeczownik wydaje się być nieco bardziej popularny niż rzeczownik + czasownik. Niektórzy używają słów kluczowych SQL (Wybierz, Wstaw, Aktualizuj, Usuń) dla czasowników, podczas gdy inni używają czasowników innych niż SQL (lub ich skrótów), takich jak Pobierz i Dodaj. Niektórzy rozróżniają rzeczowniki w liczbie pojedynczej i mnogiej, aby wskazać, czy pobierany jest jeden, czy wiele rekordów.
• W razie potrzeby na końcu sugerowane jest dodatkowe zdanie. GetCustomerById, GetCustomerBySaleDate.
• Niektórzy używają podkreślenia między segmentami nazw, a niektórzy unikają podkreślenia. app_ Get_Customer vs. appGetCustomer - wydaje mi się, że to kwestia czytelności.
• Duże zbiory sprocs można segregować na pakiety Oracle lub rozwiązania i projekty Management Studio (SQL Server) lub schematy SQL Server.
• Należy unikać niezrozumiałych skrótów.

Dlaczego wybrałem odpowiedź, którą wybrałem: Jest tak wiele dobrych odpowiedzi. Dziękuję wam wszystkim! Jak widać, bardzo trudno byłoby wybrać tylko jedną. Ten, który wybrałem, rezonował ze mną. Podążyłem tą samą ścieżką, którą opisuje - próbując użyć czasownika + rzeczownik, a następnie nie mogąc znaleźć wszystkich sprocesów, które dotyczą Klienta.

Możliwość zlokalizowania istniejącego sproc lub określenia, czy w ogóle istnieje, jest bardzo ważna. Poważne problemy mogą powstać, jeśli ktoś nieumyślnie utworzy duplikat sproc o innej nazwie.

Ponieważ generalnie pracuję nad bardzo dużymi aplikacjami z setkami sproców, preferuję najłatwiejszą do znalezienia metodę nazewnictwa. W przypadku mniejszych aplikacji mógłbym zalecić czasownik + rzeczownik, ponieważ jest zgodny z ogólną konwencją kodowania nazw metod.

Opowiada się również za dodawaniem prefiksów do nazwy aplikacji zamiast niezbyt przydatnego usp_. Jak zauważyło kilka osób, czasami baza danych zawiera pliki sproc dla wielu aplikacji. Tak więc prefiks z nazwą aplikacji pomaga segregować sprocy ORAZ pomaga administratorom baz danych i innym określić, do której aplikacji służy sproc.

W moim ostatnim projekcie użyłem usp_ [Action] [Object] [Process], więc na przykład usp_AddProduct lub usp_GetProductList, usp_GetProductDetail. Jednak teraz baza danych zawiera ponad 700 procedur, znacznie trudniej jest znaleźć wszystkie procedury dotyczące określonego obiektu. Na przykład muszę teraz przeszukać 50 nieparzystych procedur Add dla dodania produktu i 50 nieparzystych dla Get itp.

Z tego powodu w mojej nowej aplikacji planuję grupowanie nazw procedur według obiektów, porzucam również usp, ponieważ uważam, że jest on nieco zbędny, poza tym, że chcę powiedzieć mi, że jest to procedura, coś, co mogę odjąć od nazwy samą procedurę.

Nowy format jest następujący

[App]_[Object]_[Action][Process]

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

Pomaga pogrupować rzeczy, aby łatwiej je później znaleźć, zwłaszcza jeśli jest duża liczba sprocesów.

Jeśli chodzi o użycie więcej niż jednego obiektu, stwierdzam, że większość wystąpień ma obiekt podstawowy i pomocniczy, więc obiekt podstawowy jest używany w normalnym wystąpieniu, a do drugiego znajduje się odniesienie w sekcji procesu, na przykład App_Product_AddAttribute.

Oto kilka wyjaśnień dotyczących problemu z prefiksem sp_ w programie SQL Server.

Procedury składowane o nazwie z przedrostkiem sp_ to procedury systemowe przechowywane w bazie danych Master.

Jeśli nadasz swojemu sproc ten prefiks, SQL Server wyszuka je najpierw w bazie danych Master, a następnie w bazie danych kontekstu, niepotrzebnie marnując zasoby. A jeśli sproc utworzony przez użytkownika ma taką samą nazwę jak sproc systemowy, sproc utworzony przez użytkownika nie zostanie wykonany.

Prefiks sp_ ​​wskazuje, że sproc jest dostępny ze wszystkich baz danych, ale powinien być wykonywany w kontekście bieżącej bazy danych.

Oto fajne wyjaśnienie, które zawiera demo hitu wydajnościowego.

Oto kolejne pomocne źródło podane przez Anta w komentarzu.

Systemy węgierskie (podobnie jak powyższy przedrostek „usp”) przyprawiają mnie o dreszcze.

Współdzielimy wiele procedur składowanych w różnych bazach danych o podobnej strukturze, więc w przypadku baz danych specyficznych używamy przedrostka samej nazwy bazy danych; procedury współdzielone nie mają przedrostka. Przypuszczam, że użycie różnych schematów może być alternatywą dla całkowitego pozbycia się takich nieco brzydkich przedrostków.

Rzeczywista nazwa po prefiksie prawie nie różni się od nazewnictwa funkcji: zazwyczaj czasownik taki jak „Dodaj”, „Ustaw”, „Generuj”, „Oblicz”, „Usuń” itp., Po którym występuje kilka bardziej szczegółowych rzeczowników, takich jak „Użytkownik „,„ DailyRevenue ”i tak dalej.

Odpowiadając na komentarz Ant:

1. Różnica między tabelą a widokiem dotyczy tych, którzy projektują schemat bazy danych, a nie tych, którzy uzyskują dostęp do jego zawartości lub modyfikują ją. W rzadkich przypadkach, gdy potrzebne są szczegółowe informacje o schemacie, łatwo je znaleźć. W przypadku zwykłego zapytania SELECT nie ma to znaczenia. W rzeczywistości uważam, że możliwość traktowania tabel i widoków w ten sam sposób jest dużą zaletą.
2. W przeciwieństwie do funkcji i procedur składowanych jest mało prawdopodobne, aby nazwa tabeli lub widoku zaczynała się od czasownika lub była niczym innym niż jednym lub większą liczbą rzeczowników.
3. Funkcja wymaga wywołania przedrostka schematu. W rzeczywistości składnia wywołania (której używamy w każdym razie) jest bardzo różna w przypadku funkcji i procedury składowanej. Ale nawet gdyby tak nie było, zastosowanie miałoby to samo, co 1.: jeśli mogę tak samo traktować funkcje i procedury składowane, dlaczego nie?

Przez lata używałem prawie wszystkich różnych systemów. W końcu opracowałem ten, którego nadal używam:

Prefiks :

• gen - Ogólne: głównie CRUD
• rpt - Raport: nie wymaga wyjaśnień
• tsk - Zadanie: zwykle coś z logiką proceduralną, uruchamiane poprzez zaplanowane zadania

Specyfikator akcji:

Ins - INSERT
Sel - SELECT
Upd - UPDATE
Del - DELETE

(W przypadkach, gdy procedura robi wiele rzeczy, do wyboru specyfikatora akcji używany jest cel ogólny. Na przykład klient INSERT może wymagać dużo pracy przygotowawczej, ale celem ogólnym jest WSTAWIANIE, więc wybierane jest ustawienie „Ins”.

Obiekt:

W przypadku gen (CRUD) dotyczy to tabeli lub nazwy widoku. W przypadku rpt (raport) jest to krótki opis raportu. Dla tsk (Zadanie) jest to krótki opis zadania.

Opcjonalne klaryfikatory:

Są to opcjonalne fragmenty informacji służące do lepszego zrozumienia procedury. Przykłady to „Według”, „Dla” itp.

Format:

[Przedrostek] [Specyfikator działania] [Jednostka] [Opcjonalne wyjaśnienia]

Przykładowe nazwy procedur:

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

TableName_WhatItDoes

• Comment_GetByID

• Lista klientów

• UserPreference_DeleteByUserID

Żadnych przedrostków ani głupich węgierskich bzdur. Tylko nazwa tabeli, z którą jest najbardziej powiązany, i krótki opis jej funkcji.

Jedno zastrzeżenie do powyższego: osobiście zawsze poprzedzam wszystkie moje automatycznie generowane CRUD z zCRUD_, aby sortuje się do końca listy, gdzie nie muszę na to patrzeć.

Uruchamianie nazwy procedury składowanej za pomocą sp_jest złe w SQL Server, ponieważ wszystkie sprocy systemowe zaczynają się od sp_. Spójne nazewnictwo (nawet w zakresie hobgoblin-dom) jest przydatne, ponieważ ułatwia zautomatyzowane zadania w oparciu o słownik danych. Prefiksy są nieco mniej przydatne w SQL Server 2005, ponieważ obsługuje schematy, których można używać dla różnych typów przestrzeni nazw w taki sam sposób, jak prefiksy w używanych nazwach. Na przykład na schemacie gwiaździstym można by mieć schematy ciemności i faktów oraz odwoływać się do tabel zgodnie z tą konwencją.

W przypadku procedur składowanych prefiksowanie jest przydatne w celu identyfikacji sprocesów aplikacji ze sprocesów systemowych. up_vs. sp_sprawia, że ​​stosunkowo łatwo jest zidentyfikować niesystemowe procedury składowane w słowniku danych.

Zawsze hermetyzuję procedury składowane w pakietach (w pracy używam Oracle). Zmniejszy to liczbę oddzielnych obiektów i pomoże w ponownym wykorzystaniu kodu.

Konwencja nazewnictwa to kwestia gustu i coś, co powinieneś uzgodnić ze wszystkimi innymi programistami na początku projektu.

w przypadku małych baz danych używam uspTableNameOperationName, np. uspCustomerCreate, uspCustomerDelete itp. Ułatwia to grupowanie według „głównej” jednostki.

w przypadku większych baz danych dodaj schemat lub nazwę podsystemu, np. Odbieranie, Kupowanie, itp., aby je pogrupować (ponieważ serwer sql lubi wyświetlać je alfabetycznie)

staram się unikać skrótów w nazwach, dla jasności (a nowe osoby w projekcie nie muszą się zastanawiać, co oznacza `` UNAICFE '', ponieważ sproc nazywa się uspUsingNoAbbreviationsIncreasesClarityForEveryone)

Obecnie używam formatu podobnego do następującego

Notacja:

[PREFIX] [APLIKACJA] [MODUŁ] _ [NAZWA]

Przykład:

P_CMS_USER_UserInfoGet

Podoba mi się ten zapis z kilku powodów:

• rozpoczęcie od bardzo prostego Prefiksu pozwala na pisanie kodu tylko do wykonywania obiektów zaczynających się od prefiksu (np. w celu zmniejszenia iniekcji SQL)
• w naszym większym środowisku wiele zespołów pracuje nad różnymi aplikacjami, które działają na tej samej architekturze bazy danych. Notacja aplikacji wskazuje, która grupa jest właścicielem SP.
• Sekcje Module i Name po prostu uzupełniają heirarchię. Wszystkie nazwy powinny mieć możliwość dopasowania do grupy / aplikacji, modułu, funkcji z hierarchii.

Zawsze używam:

usp [nazwa tabeli] [akcja] [dodatkowe szczegóły]

Biorąc pod uwagę tabelę o nazwie „tblUser”, otrzymuję:

• uspUserCreate
• uspUserSelect
• uspUserSelectByNetworkID

Procedury są posortowane alfabetycznie według nazwy tabeli i funkcjonalności, więc łatwo jest zobaczyć, co mogę zrobić dla dowolnej tabeli. Użycie przedrostka „usp” pozwala mi wiedzieć, do czego dzwonię, jeśli (na przykład) piszę 1000-liniową procedurę, która współdziała z innymi procedurami, wieloma tabelami, funkcjami, widokami i serwerami.

Dopóki edytor w SQL Server IDE nie będzie tak dobry jak Visual Studio, zachowuję prefiksy.

aplikacja przedrostek_ operacja prefiks_ opis zaangażowanych obiektów bazy danych (bez spacji między podkreśleniami - trzeba było wstawić spacje, aby się pojawiły) .

przedrostki operacji, których używamy -

• „ Get ” - zwraca zestaw rekordów
• „ Ins ” - wstawia dane
• „ Upd ” - aktualizuje dane
• „ Del ” - usuwa dane

na przykład

wmt_ ins _ customer _details

„narzędzie do zarządzania siłą roboczą, wstaw szczegóły do ​​tabeli klientów”

Zalety

Wszystkie procedury składowane dotyczące tej samej aplikacji są pogrupowane według nazwy. W grupie zgrupowane są procedury składowane, które wykonują ten sam rodzaj operacji (np. Wstawienia, aktualizacje itp.).

Ten system działa u nas dobrze, mając ok. 1000 procedur składowanych w jednej bazie danych.

Jak dotąd nie spotkałem się z żadnymi wadami tego podejścia.

GetXXX - Pobiera XXX na podstawie @ID

GetAllXXX - Pobiera wszystkie XXX

PutXXX - wstawia XXX, jeśli przekazano @ID wynosi -1; inne aktualizacje

DelXXX - usuwa XXX na podstawie @ID

Myślę, że konwencja nazewnictwa usp_ nikomu nie pomaga.

W przeszłości używałem prefiksów Get / Update / Insert / Delete dla operacji CRUD, ale teraz, odkąd używam Linq do SQL lub EF do wykonywania większości mojej pracy CRUD, te całkowicie zniknęły. Ponieważ mam tak mało przechowywanych procesów w moich nowych aplikacjach, konwencje nazewnictwa nie mają już znaczenia tak jak kiedyś ;-)

Dla obecnej aplikacji, nad którą pracuję, mamy prefiks identyfikujący nazwę aplikacji (cztery małe litery). Powodem tego jest to, że nasza aplikacja musi być w stanie współistnieć ze starszą aplikacją w tej samej bazie danych, więc prefiks jest koniecznością.

Gdybyśmy nie mieli wcześniejszego ograniczenia, jestem pewien, że nie używalibyśmy przedrostka.

Po przedrostku zwykle zaczynamy nazwę SP od czasownika opisującego, co robi procedura, a następnie nazwę jednostki, na której działamy. Dopuszczalna jest pluralizacja nazwy podmiotu - staramy się podkreślić czytelność, aby było oczywiste, co robi procedura z samej nazwy.

Typowe nazwy procedur składowanych w naszym zespole to:

shopGetCategories
shopUpdateItem

Nie sądzę, żeby to naprawdę miało znaczenie, jaki jest twój prefiks, o ile jesteś logiczny i spójny. Osobiście używam

spu_ [opis akcji] [opis procesu]

gdzie opis akcji jest jedną z kilku typowych akcji, takich jak pobieranie, ustawianie, archiwizacja, wstawianie, usuwanie itp. Opis procesu jest krótki, ale opisowy, na przykład

spu_archiveCollectionData 

lub

spu_setAwardStatus

Moje funkcje nazywam podobnie, ale przedrostek z udf_

Widziałem, jak ludzie próbowali używać notacji pseudowęgierskiej do nazewnictwa procedur, co moim zdaniem bardziej ukrywa niż ujawnia. Tak długo, jak wymieniam swoje procedury alfabetycznie, widzę je pogrupowane według funkcjonalności, to wydaje mi się, że jest to najlepszy punkt między porządkiem a niepotrzebnym rygorem

Unikaj sp_ * na serwerze SQl, ponieważ wszystkie procedury przechowywane w systemie zaczynają się od sp_ i dlatego systemowi trudniej jest znaleźć obiekt odpowiadający nazwie.

Więc jeśli zaczniesz od czegoś innego niż sp_, sprawy staną się łatwiejsze.

Więc na początek używamy wspólnego nazewnictwa Proc_. Ułatwia to identyfikację procedur, jeśli zostanie przedstawiony jeden duży plik schematu.

Oprócz tego przypisujemy przedrostek identyfikujący funkcję. Lubić

Proc_Poll_Interface, Proc_Inv_Interface itp.

To pozwala nam znaleźć wszystkie przechowywane procesy, które wykonują zadanie POLL w porównaniu z tym, co robi Inventory itp.

W każdym razie system prefiksów zależy od domeny, z którą masz problem. Ale wszyscy powiedzieli i zrobili coś podobnego, nawet jeśli ma to na celu umożliwienie ludziom szybkiego zlokalizowania procedury składowanej w rozwijanym oknie eksploratora do edycji.

inne np. funkcji.

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

Postępowaliśmy zgodnie z nazewnictwem opartym na funkcjach, ponieważ Procesy są podobne do kodu / funkcji, a nie do obiektów statycznych, takich jak tabele. Nie pomaga to, że Procs może pracować z więcej niż jedną tabelą.

Jeśli proc wykonywał więcej funkcji, niż może być obsłużonych w jednej nazwie, oznacza to, że twój proc robi o wiele więcej niż to konieczne i czas na ponowne ich podzielenie.

Mam nadzieję, że to pomoże.

Dołączyłem późno do wątku, ale tutaj chcę wpisać swoją odpowiedź:

W moich ostatnich dwóch projektach są różne trendy, jak w jednym zastosowaliśmy:

Aby uzyskać dane: s <nazwa tabeli> _G
Aby usunąć dane: s < nazwa tabeli > _D
Aby wstawić dane: s < nazwa tabeli> _I Aby zaktualizować dane: s <nazwa tabeli
> _U

Te konwencje nazewnictwa są również przestrzegane w interfejsie użytkownika, poprzedzając słowo dt .

Przykład:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

Dzięki powyższym konwencjom nazewnictwa w naszej aplikacji mamy dobre i łatwe do zapamiętania nazwy.

Podczas gdy w drugim projekcie zastosowaliśmy te same konwencje nazewnictwa, z niewielką różnicą:

Aby uzyskać dane: sp_ <nazwa tabeli> G
Aby usunąć dane: sp_ <nazwa tabeli> D
Aby wstawić dane: sp_ <nazwa tabeli> I
Aby zaktualizować dane: sp_ <nazwa tabeli> U

Przykład:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU