Czy ktoś może polecić standardy kodowania dla TSQL?

9

Od dawna mamy standardy kodowania naszego kodu .Net i wydaje się, że istnieje kilka renomowanych źródeł pomysłów na ich stosowanie, które ewoluują z czasem.

Chciałbym móc opracować pewne standardy dla SQL napisanego do użytku przez nasze produkty, ale wydaje się, że nie ma żadnych zasobów na temat konsensusu co do tego, co determinuje dobrze napisany SQL?

Rowland Shaw
źródło
1
Pinal Dave ma na swojej stronie listę standardów kodowania . Wyglądają jak uczciwa podstawa dla zestawu standardów.
Will A
1
Jest powiązany pytanie na SO .
Scott Whitlock,
1
@Scott, który obejmuje tylko identyfikację; nic na temat nazewnictwa, używania kursorów / procedur przechowywanych / wyborów typu danych lub czegokolwiek, co faktycznie wpływa na jakość kodu ...
Rowland Shaw
1
właśnie dlatego powiedziałem, że to „spokrewnione”, a nie „duplikat”.
Scott Whitlock,

Odpowiedzi:

6

Z mojego doświadczenia wynika, że ​​głównymi rzeczami, których szukałem, byłyby:

  • Nazwy tabel i kolumn - sprawdź, czy używasz identyfikatora, numeru referencyjnego lub numeru dla kolumn typu ID, liczby pojedynczej czy mnogiej dla nazw (liczby mnogie są wspólne dla nazw tabel - np. RZECZY, liczby pojedynczej dla nazw kolumn - np. ID_RÓŻNICY). Dla mnie najważniejsze są tutaj spójność, która pozwala ludziom nie marnować czasu (na przykład nie wpadasz na literówki, w których ktoś umieścił RZECZ jako nazwę tabeli, ponieważ intuicyjnie wiesz, że nazwy tabel nigdy nie są osobliwe).

  • Wszystkie tworzone powinny zawierać upuszczenie (zależnie od istniejącego obiektu) jako część ich pliku. Możesz także dołączyć uprawnienia do przyznawania, zależnie od ciebie.

  • Zaznaczenia, aktualizacje, wstawki i usunięcia powinny być oznaczone jedną nazwą kolumny, jedną nazwą tabeli i jedną, w której klauzula / kolejność według klauzuli na wiersz, aby można je było łatwo komentować pojedynczo podczas debugowania.

  • Prefiks dla typów obiektów, szczególnie tam, gdzie można je pomylić (więc v, aby widok był najważniejszy). Nie jestem pewien, czy nadal ma zastosowanie, ale wcześniej było niewydajne, aby procedury składowane inne niż procedury systemowe zaczęły sp_. Prawdopodobnie najlepszą praktyką ich rozróżnienia i tak było usp_, którego ostatnio używałem.

  • Standard wskazujący, w jaki sposób nazwa wyzwalacza powinna obejmować to, czy dotyczy aktualizacji / wstawiania / usuwania oraz tabelę, której dotyczy. Nie mam preferowanego standardu, ale jest to informacja krytyczna i musi być łatwa do znalezienia.

  • Standard własności obiektów we wcześniejszych wersjach SQL Server lub schemat, który powinien istnieć w 2005 roku i później. To twoja rozmowa, jaka jest, ale nigdy nie powinieneś zgadywać, kto jest właścicielem / gdzie to mieszka) i tam, gdzie to możliwe, schemat / właściciel powinien zostać uwzględniony w skryptach CREATE, aby zminimalizować możliwość jego błędnego utworzenia.

  • Wskaźnik, że każdy, kto użyje WYBIERZ *, będzie zmuszony wypić pół litra własnego moczu.

  • O ile nie istnieje naprawdę, bardzo dobry powód (który nie obejmuje lenistwa z twojej strony), od samego początku stosuj i utrzymuj relacje między kluczem podstawowym / kluczem obcym. Jest to przecież relacyjna baza danych, a nie płaski plik, a osierocone rekordy w pewnym momencie sprawią, że wasze wsparcie stanie się piekłem. Pamiętaj też, że jeśli nie zrobisz tego teraz, mogę obiecać, że nigdy nie uda ci się go wdrożyć po wydarzeniu, ponieważ jest to 10-krotność pracy, gdy masz dane (co będzie trochę popieprzone, ponieważ nigdy nie egzekwowałeś relacje prawidłowo).

Jestem pewien, że coś przeoczyłem, ale dla mnie to te, które naprawdę oferują realne korzyści w przyzwoitej liczbie sytuacji.

Ale jak w przypadku wszystkich standardów, mniej znaczy więcej. Im dłuższe standardy kodowania, tym mniej prawdopodobne jest, że ludzie będą je czytać i używać. Po przejściu przez kilka dobrze rozmieszczonych stron zacznij szukać rzeczy, które tak naprawdę nie mają praktycznej różnicy w prawdziwym świecie, ponieważ po prostu zmniejszasz ryzyko, że ludzie to zrobią.

EDYCJA: dwie poprawki - w tym schematy w części własności, usunięcie błędnej wskazówki dotyczącej liczenia (*) - patrz komentarze poniżej.

Jon Hopkins
źródło
1
Jakieś dziwne wybory ... „WYBIERZ LICZBĘ (*)” jest zły? Słyszałeś kiedyś o schematach (które nie są tym samym co właściciel)? Ale inni są dobrzy
gbn
1
@Jon Hopkins - Wiem, dlaczego źle jest używać SELECT *. Byłoby wspaniale, gdybyś mógł powiedzieć, dlaczego używanie WYBIERZ LICZBĘ (*) jest złe.
k25
1
@gbn @ k25 - Kilka lat temu (2002?) Miałem DBA, który był bardzo lubiący liczenie (*), ale Googling w odpowiedzi na twoje pytania wydaje się, że jest to obecnie nieaktualne (jeśli to kiedykolwiek prawda). sqlservercentral.com/articles/Performance+Tuning/adviceoncount/… (wymagana rejestracja). Była przede wszystkim Oracle DBA, więc może to być prawdziwy problem, który, jak zakładała, był również problemem dla optymalizatora SQL.
Jon Hopkins
1
@gbn - Tak, chociaż byłem stosunkowo wolny od czasu ich wprowadzenia, więc moją automatyczną reakcją byli użytkownicy. Zaktualizuję odpowiedź, aby objąć schematy.
Jon Hopkins
1
@gbn, @ k25 - Więcej kopania przy liczeniu (*). Najwyraźniej był to problem w Oracle 7 i wcześniejszych, naprawiony w 8i i późniejszych. Nie jest jasne, czy kiedykolwiek był to problem w SQL Server, ale na pewno już nie jest. Wydaje się, że mój DBA był przestarzały.
Jon Hopkins
3

wydaje się, że nie ma żadnych zasobów na temat konsensusu co do tego, co determinuje dobrze napisany SQL

To dlatego, że nie ma konsensusu. Jako przykład, miałbym różne odpowiedzi na co najmniej połowę pozycji na liście Jona Hopkinsa, a na podstawie ilości szczegółów na jego liście można zgadywać, że oboje pracujemy z bazami danych na życie.

To powiedziawszy, standard kodowania jest nadal dobrą rzeczą, a standard, który wszyscy w zespole rozumieją i zgadzają się z nim, jest lepszą rzeczą, ponieważ bardziej prawdopodobne jest przestrzeganie tego standardu.

Larry Coleman
źródło
1
+1. Myślę, że najważniejsze jest to, że masz spójność w swoim zespole.
Dean Harding
1
poza zainteresowaniem, co zrobiłbyś inaczej? Czy są to w dużej mierze kwestie gustu (układ i tak dalej), czy są jakieś „twarde” błędy?
Jon Hopkins
1
@Jon: brak ostrych błędów, tylko subiektywne rzeczy, takie jak pojedyncze nazwy tabel, nienawiść do wyzwalaczy itp. BTW, „SELECT *” jest w porządku w „EXISTS ()”.
Larry Coleman
1
uczciwy przykład (i używam go z ISTNIENIEM i nie zmuszam się do picia moczu).
Jon Hopkins
1

Oprócz odpowiedzi Jona Hopkinsa ...

  • Oddziel obiekty wewnętrzne od zewnętrznych

    • IX, UQ, TRG, CK itp. Dla ograniczeń i indeksów itp
    • małe litery lub CapsCase dla klienta skierowanego np. uspThing_Add
  • W przypadku obiektów wewnętrznych wyraź je, jeśli „inne niż domyślne”

    • UQ = unikalne ograniczenie
    • UQC = unikalne ograniczenie klastrowe
    • PK = klucz podstawowy
    • PKN = nieklastrowany klucz podstawowy
    • IX = indeks
    • IXU = unikalny indeks
    • IXC = indeks klastrowy
    • IXCU lub IXUC = unikalny indeks klastrowy
  • Użyj schematów, aby uprościć nazewnictwo + uprawnienia. Przykłady:

    • Helper.xxx dla wewnętrznych procesów
    • HelperFn.xxx dla udfs
    • WebGUI.xxx dla niektórych stojących kodów
    • Dane i / lub Historia i / lub Inscenizacja tabel
gbn
źródło