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


122

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.


1
Co oznacza usp?
Midhat

2
Uważam, że usp to skrót od „procedury użytkownika”. To odróżnia go od procedur systemowych z prefiksem „sp_”. To ważne rozróżnienie, o czym możesz przeczytać w odpowiedziach.
DOK

dzięki dok. grazie mille
Midhat


1
Głosuję za tym tylko dlatego, że jest zamknięty, mam nadzieję, że pokazuję moce, że takie pytania są przydatne dla społeczności.
tsilb

Odpowiedzi:


66

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.


3
A jeśli w grę wchodzi więcej niż jeden obiekt? Na przykład, co się stanie, jeśli sproc zapyta o informacje zarówno z tabeli Klient, jak i Zamówienia?
DOK

2
Dzięki Mitch, wyjaśnijmy. Ten przedrostek „Aplikacja” jest symbolem zastępczym innego skrótu wskazującego nazwę (lub akronim) rzeczywistej aplikacji. Gdy 3 aplikacje współużytkują jedną bazę danych, mogą istnieć ICA_Product_Add, CRM_Product_Add i BPS_Product_Add.
DOK

2
Dlaczego miałbyś powielać każdą procedurę 3 razy dla 3 aplikacji? Cały sens procedur sklepowych polega na tym, aby mieć jedno miejsce, w którym dzieje się dana czynność. „ICA_Product_Add, CRM_Product_Add i BPS_Product_Add” to niszczy.
Jason Kester

3
Jason, te sprocy mogą wstawiać do różnych tabel. Mogą mieć różne parametry wejściowe lub zwracać wartości. Lub mogą zachowywać się inaczej. Jeśli sprocy robią to samo, zgadzam się, powinna być tylko jedna wersja. Jak zasugerował ktoś inny, współdzielone sprocy mogą nie mieć przedrostka.
DOK,

1
Jeśli masz wiele aplikacji wywołujących tę samą procedurę, musisz być bardzo ostrożny, każda modyfikacja tego proca może spowodować uszkodzenie tych wielu aplikacji. Mądre nazewnictwo jest to szara strefa, ale możesz nazwać ją powszechną / globalną lub cokolwiek uznasz za stosowne. @localghosts: dzięki za informacje.
dnolan

36

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.


Hmm, nie rozumiem. Dlaczego SP jest hitem wydajnościowym? Czy usp lub gsp jest w porządku?
Erwin Rooijakkers

1
@ user2609980 DOK mówi, że SQL Server wyszukuje sp_wstępnie prefiksowany proces w Master DB, a następnie w bieżącej DB, jeśli nie zostanie znaleziony
GôTô

+1 za wyraźne stwierdzenie czegoś, co gdzie indziej ma bardziej zawiłe wyjaśnienia. Nie jest to dla mnie nowość, ale myślę, że jest to proste i zwięzłe wyjaśnienie dla kogoś, kto zaczyna.
podkreśl

Odnośnik do wersji demonstracyjnej tego hitu wydajnościowego pochodzi z artykułu napisanego w 2001 roku. Od tego czasu zmienił się, oto dokładniejszy artykuł (od 2012) autorstwa Aarona Bertranda: sqlperformance.com/2012/10/t-sql-queries/sp_prefix
Michael J Swart

16

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?

1
Więc skąd wiesz, czy wchodzisz w interakcję z procedurą, funkcją, widokiem, tabelą lub czymkolwiek innym?
Ant

1
Wyobrażam sobie, że funkcje mogą zaczynać się od „Get” lub być nazwą, która nie zaczyna się od czasownika. Wszystko inne byłoby procedurą, ponieważ w końcu nazywa się je procedurami składowanymi. Procedury ukrywają szczegóły, takie jak widoki, tabele i wszystko inne.
Mark Stock

3
Ale to nie jest węgierski. „Usp” nie jest węgierską deklaracją zmiennej. Litera „u” nie oznacza „aktualizacji”, oznacza „użytkownika”, jak w przypadku „procedury składowanej zdefiniowanej przez użytkownika” i chroni jedynie przed zaglądaniem przez SQL Server do głównej bazy danych za każdym razem, gdy szuka procedury składowanej. Oczywiście są inne sposoby, ale „usp” jest powszechnie uważane za standard w wielu korpusach iz tego, co widziałem, działa dobrze. Jest również nauczany przez Microsoft i zalecaną przez Microsoft konwencję nazewnictwa: msdn.microsoft.com/en-us/library/ms124456(v=SQL.100).aspx
asus3000

10

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

4
Teraz jest interesujące podejście do przedrostka. Wygląda to na dobry sposób na segregację sprocesów według ich użycia.
DOK

10

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ć.


Oddzielenie pozycji „z” od reszty wydaje się świetnym pomysłem.
DOK

Podoba mi się ta metoda. Muszą być łatwe do znalezienia. Kiedy przeglądam listę czasowników pierwszych sprocs i widzę 200 pobrań, 200 wstawek, 200 aktualizacji, trudno jest znaleźć wszystkie dla określonej tabeli lub grupy. Najpierw użyłem metody czasowników i szybko robi się bałagan. Nazwa tabeli najpierw rozwiązuje ten problem. Na przykład powyżej w odpowiedzi wszystkie Twoje uwagi lub komentarze klientów byłyby zgrupowane razem, łatwe do znalezienia.
astrosteve

1
A co, jeśli masz zapytanie łączące kilka tabel?
leandronn

10

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.


2
Nazywanie sprocs „sp_” jest również bardzo złym pomysłem ze względu na szybkość, ponieważ SQL Server próbuje zoptymalizować swoje wyszukiwania dla tych, opierając się na założeniu, że są to procedury systemowe. Spójrz tutaj, piąty punkt w dół: rakph.wordpress.com/2008/04/19/tips-store-procedure
Ant

4

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.


Pakiety są dobre. Począwszy od SQL Server 2005, Management Studio umożliwia tworzenie „rozwiązań” do przechowywania powiązanych sprocsów i innych instrukcji SQL.
DOK

2
@DOK - zauważ, że te pakiety nie mają jednak żadnego śladu w samej bazie danych. Są czysto artefaktami narzędzia front-end. Nie możesz wyszukiwać według pakietu w słowniku danych. Pakiety Oracle są obiektami pierwszej klasy w systemowym słowniku danych i mają swój własny zakres.
ConcernedOfTunbridgeWells

4

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)


Tak, dziękuję szczególnie za zajęcie się skrótami.
DOK

@ [DOK]: nie ma za co - co, bez głosów za? ;-)
Steven A. Lowe

Steve, masz głos za. Byłem zbyt zajęty czytaniem lawiny odpowiedzi i komentarzy, i zadręczaniem się, która odpowiedź jest „najlepsza”.
DOK

@ [DOK]: dzięki; „najlepsza” odpowiedź to prawdopodobnie kombinacja, która ma sens w Twojej sytuacji.
Steven A. Lowe

4

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.

2

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.


2

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.


Generalnie brzydzę się używaniem podkreśleń, ale sposób, w jaki ich używasz - nie tylko do segregowania prefiksu, ale także do segregowania operacji - ułatwiłby znalezienie go podczas skanowania listy setek sprocesów. Pretty_neat_idea.
DOK

2

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


1

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ś ;-)


1
Przedrostek każdego sproc z _usp nie pomaga w rozróżnieniu między nimi. Myślę, że niektórzy DBA są podobni do tego prefiksu, ponieważ wskazuje typ obiektu bazy danych. Może usłyszymy od jednego z nich, który to lubi.
DOK

1

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

Cóż, nigdy nie wiadomo, kiedy pracujesz nad bazą danych przeznaczoną dla jednej aplikacji, czy później będzie inna aplikacja korzystająca z tej samej bazy danych. W twojej sytuacji z pewnością pomaga to w segregacji sprocesów.
DOK

1

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


spu_, interesujące. Pomija problem SQL Server sp_.
DOK

1

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.


1

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

Ciekawy. Nigdy nie widziałem, żeby było to zrobione w ten sposób, ale łatwo jest zapamiętać lub odgadnąć prawidłowe nazwy.
DOK,

1
Dzięki DOK, tak, jest łatwy do zapamiętania, a my jako deweloperzy nie czujemy się skomplikowani w nazwach
Gaurav Aroraa

9
Dlaczego nie _C _R _U _D?
kiedy

@onedaywhen - to dobry pomysł, zasugeruję naszemu administratorowi, abyśmy mogli odpowiednio zachować konwersje nazw. Ale głównym motywem tej konwencji nazewnictwa jest poprawne przedstawienie całego obiektu, chyba że coś przeoczyłem ...
Gaurav Aroraa

1
Prefiks „sp_” nie jest zalecany.
Piyey
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.