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

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?

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.

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.

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