Jakie są najbardziej przydatne standardy baz danych?

• Nazwij podobnie adresowane przechowywane proc z tym samym prefiksem, na przykład jeśli masz 3 procedury przechowywane dla osoby. W ten sposób wszystko dla osoby jest zgrupowane w jednym miejscu i można je łatwo znaleźć bez konieczności przeglądania wszystkich swoich procs, aby je znaleźć.
  • PersonUpdate
  • PersonDelete
  • PersonCreate
• wykonuj podobne czynności dla tabel, gdy masz grupy tabel z powiązanymi danymi. Na przykład:
  • InvoiceHeaders
  • InvoiceLines
  • InvoiceLineDetails
• Jeśli masz opcję schematów w swojej bazie danych, użyj ich. O wiele milej jest widzieć:
  • Faktura.Header
  • Faktura.KolejkaItems
  • Faktura.KolejkaPozycji.Szczegóły
  Osoba.Update
Osoba.Delete Osoba.Create

Jedna rzecz, o której jeszcze nie wspomniałem:

Nigdy nie używaj słów kluczowych bazy danych jako nazw obiektów. Nie chcesz ich kwalifikować za każdym razem, gdy ich używasz

Jeśli podczas tworzenia czegoś błędnie piszesz, napraw to tak szybko, jak to zauważysz. Nie spędzaj lat, aby pamiętać, że w tej tabeli Nazwa użytkownika jest naprawdę Usernmae. Jest to o wiele łatwiejsze do naprawienia, gdy nie ma dużo kodu napisanego przeciwko niemu.

Nigdy nie używaj łączników implikowanych (składnia przecinka), zawsze podaj / align = "left" /

Moje standardy dla Oracle to:

• słowa kluczowe są zawsze pisane wielkimi literami;
• nazwy obiektów bazy danych są zawsze pisane małymi literami;
• podkreślniki zastąpią spacje (tzn. nie będzie żadnych konwencji wielbłądów, które są wspólne na przykład na serwerze SQL);
• klucze podstawowe będą praktycznie zawsze nazywane 'id';
• będzie egzekwowana integralność odniesienia;
• wartościami całkowitymi (w tym id tabeli) będą zazwyczaj zawsze liczba (19,0). Powodem tego jest to, że będzie to pasować do 64-bitowej, podpisanej liczby całkowitej, co pozwoli na użycie typu Java long zamiast bardziej niewygodnego BigInteger;
• pomimo błędnej nazwy dodawania "_number" do niektórych nazw kolumn, typem takich kolumn będzie VARCHAR2, a nie Typ liczby. Typy liczb są zarezerwowane dla kluczy podstawowych i kolumn, na których wykonujesz arytmetykę;
• Zawsze używam technicznych klawiszy podstawowych; i
• każda tabela będzie miała własną sekwencję generowania kluczy. Nazwa tej sekwencji będzie brzmiała _seq.

W SQL serverze jedyną modyfikacją jest użycie wielbłąda dla nazw obiektów bazy danych (tj. PartyName zamiast party_name).

Zapytania będą zazwyczaj zapisywane w wielu wierszach z jednym klauzulą lub warunkiem na linię:

SELECT field1, field2, field2
FROM tablename t1
JOIN tablename2 t2 ON t1.id = t2.tablename_id
WHERE t1.field1 = 'blah'
AND t2.field2 = 'foo'

Jeśli klauzula SELECT jest wystarczająco długa, podzielę ją na jedno pole na linię.

• Wymień wszystkie ograniczenia

Nie zapomnij regularnie tworzyć kopii zapasowych swoich baz danych.

1. Nie używaj nazw typów w nazwach pól. Starsi ludzie zapamiętają stary standard MS lpsz i głupotę, która z tego wynikła.

2. Używaj opisowych nazw pól zgodnych z normalnymi konwencjami językowymi. Na przykład "FirstName" zamiast "NameFirst"

3. Każde słowo w nazwie pola jest pisane wielką literą

4. Brak podkreślenia

5. Nie używaj zwykłych słów kluczowych, takich jak"Index"

6. Nie przedrostek niczego z typem obiektu. Na przykład nie używamy tblCustomers ani spCustomersGet. Nie pozwalają one na dobre sortowanie i zapewniają wartość zerową.

7. Użyj schematów do definiowania oddzielnych obszarów bazy danych. Takich jak sprzedaż.Klientów i pracowników hr. Pozwoli to pozbyć się większości prefiksów używanych przez ludzi.

8. Pętle wszelkiego rodzaju powinny być postrzegane z podejrzliwością. Zazwyczaj jest lepszy sposób na ustawienie.

9. Użyj widoków dla skomplikowanych / align = "left" /

10. Unikaj skomplikowanych połączeń, gdy to możliwe. To może być bardziej asteticaly miło mieć CustomerPhoneNumbers tabeli; ale szczerze, ile numerów telefonów naprawdę musimy przechowywać? Wystarczy dodać pola do tabeli klientów. Twoje zapytania DB będą szybsze i łatwiejsze do zrozumienia.

11. Jeśli jedna tabela wywoła pole "EmployeeId", to każda tabela, do której się odwołuje, powinna używać tej nazwy. Nie trzeba go nazywać CustomerServiceRepId tylko dlatego, że jest w tabeli rozszerzeń.

12. Prawie wszystkie stoły mają końcówkę "s". Na przykład: klienci, zamówienia itp. Po tym wszystkim tabela posiada wiele rekordów...

13. Oceniaj swoje zapytania, indeksy i relacje z kluczami zagranicznymi za pomocą narzędzia analitycznego. Nawet te, które mogą być generowane dla Ciebie. Możesz być zaskoczony.

14. Tabele łączące obsługujące wiele do wielu relacji mają obie połączone tabele w nazwie. Na przykład szkoły. Bardzo łatwo jest stwierdzić po nazwie tabeli, co robi.

15. Bądź konsekwentny. Jeśli zaczniesz jedną ścieżką ze swoimi konwencjami, nie zmieniaj koni w połowie, chyba że jesteś skłonny do refaktoryzacji wszystkich poprzednich prac. To powinno hamować na każdym "czy nie byłoby wspaniale, gdyby.."pomysły, które powodują zamieszanie i ogromne ilości przeróbek.

16. Pomyśl zanim zaczniesz pisać. Czy naprawdę potrzebujesz tej tabeli, pola, sproc, czy widoku? Jesteś pewien, że nie jest gdzieś zakryte else? Pobierz concensus przed dodaniem go. A jeśli z jakiegoś powodu musisz go wyjąć, najpierw porozmawiaj ze swoim zespołem. Byłem w miejscach, gdzie DBA codziennie wprowadza zmiany, bez względu na deweloperów. To nie jest zabawne.

Jeśli baza danych jest przeznaczona dla konkretnej aplikacji, miej tabelę wersji, dzięki której wydania bazy danych mogą być sprawdzane między innymi pod względem wersji kodu.

Zawsze staram się nie używać typu w nazwie pola - "sfirstname", "sLastName" lub "iEmployeeID". Podczas gdy na początku pasują, jeśli coś się zmieni, będą one zsynchronizowane, a zmiana tych nazw jest ogromnym bólem głowy, ponieważ musisz również zmienić zależne obiekty.

Intellisense i narzędzia GUI sprawiają, że trywialne jest sprawdzenie, jaki typ kolumny jest, więc nie uważam, że jest to konieczne.

Klauzula WITH naprawdę pomaga podzielić zapytania na łatwe do zarządzania części.

To również naprawdę pomaga w wydajności na planach realizacji zapytań.

Upewnij się, że każdy wybór varchar/nvarchar jest odpowiedni.

Upewnij się, że każdy wybór kolumny NULLable jest właściwy - unikaj kolumn NULLable, jeśli to możliwe - dopuszczanie NULL powinno być uzasadnioną pozycją.

Niezależnie od innych reguł, których możesz użyć z sugestii tutaj, chciałbym utworzyć procedurę składowaną w bazie danych, która może być uruchamiana regularnie, aby określić stan systemu dla wszelkich reguł lub standardów, które masz (niektóre z nich to trochę SQL-Server "specific"): {]}

• Szukanie osieroconych rekordów w przypadkach, w których nie można z jakiegoś powodu użyć referencyjnej integralności systemu DBMS (w moim systemie mam tabelę procesów i tabelę testów - więc mój system_health SP szuka procesów bez testów, ponieważ mam tylko jednokierunkową relację FK)

• Szukaj pustych schematów

• Szukaj tabel bez kluczy podstawowych

• Szukaj tabel bez żadnych indeksy

• Szukać obiektów bazy danych bez dokumentacji (do umieszczenia dokumentacji w bazie danych używamy właściwości SQL Server Extended properties - dokumentacja ta może być tak ziarnista jak Kolumna ).

• Poszukaj problemów specyficznych dla systemu - tabel, które wymagają archiwizacji, wyjątków, które nie są częścią normalnego miesięcznego lub codziennego przetwarzania, pewnych wspólnych nazw kolumn z domyślnymi wartościami lub bez nich (powiedzmy CreateDate).

• Szukaj niedeterministyczne UDFs

• Poszukaj komentarzy TODO, aby upewnić się, że kod w DB nie ma w jakiś sposób niesprawdzonego lub przedpremierowego kodu.

Wszystko to można zautomatyzować, aby dać ogólny obraz stanu systemu.

Każdy zapisuje zapytania SQL (widoki, procedury składowane itp.) w tym samym podstawowym formacie. To naprawdę pomaga w rozwoju/utrzymaniu wysiłków w dół drogi.

Spójne standardy nazewnictwa. Posiadanie wszystkich na tej samej stronie, przy użyciu tego samego formatu (niezależnie od tego, czy jest to Wielbłąd, konkretne prefiksy itp..) pomaga w utrzymaniu systemu dokładnie.

Kilka lubi i nie lubi.

Moim zdaniem prefiksy są okropne pod każdym względem. Obecnie pracuję nad systemem, w którym tabele są poprzedzone prefiksem, a kolumny w tabelach są poprzedzone 2-literowymi akronimami nazwy tabeli, marnuję co najmniej 30 minut każdego dnia pracując nad tą bazą danych, ponieważ akronim nie jest logiczny. Jeśli chcesz oznaczać coś z prefiksem, użyj zamiast tego właściciela schematu.

Używanie NVarchar od początku projektu, jeśli jest choćby mała wskazówka, że w dół linii dane tekstowe będą musiały obsługiwać znaki wielojęzyczne. Modernizacja dużych baz danych z powodu braku planowania i myślenia w przyszłości jest uciążliwa i marnuje czas.

Dzielenie każdego warunku w klauzuli where na nowy wiersz dla czytelności (W i nie w instrukcjach owiniętych w nawiasy i w zakładkach.) Myślę, że jest to dla mnie ważny standard.

Pracowałem w jednej firmie, gdzie standardem było to, że przecinki muszą być zawsze umieszczone na początku linii, gdy wykonywanie deklaracji parametrów lub zmiennych. To najwyraźniej uczyniło go bardziej czytelnym, jednak uznałem go za kompletny koszmar.

Oprócz normalizacji do 3NF lub BCNF (więcej o tym w to pytanie), uznałem za przydatne następujące:

• nazwy tabel jako rzeczowniki liczby mnogiej
• nazwy kolumn jako sigular

Więc tabela "ludzie" ma kolumnę "PersonID".

• nie ma nic złego w kluczach złożonych, o ile Zasady 3NF lub BCNF nadal obowiązują. W wielu przypadkach (np. w przypadku" wielu do wielu") jest to całkowicie pożądane.
• unikaj powtarzania nazwa tabeli w nazwach kolumn. peoplePersonID jest lepiej napisane jako tabela.felietony i dużo bardziej czytelne, a co za tym idzie samodokumentujące. Osób.PersonID jest lepszy, przynajmniej dla mnie.
• przy kasowaniu kaskady należy stosować bardzo ostrożnie.
• pamiętaj, że NULL oznacza jedną z dwóch rzeczy: albo jest nieznana, albo nie ma zastosowania.
• Pamiętaj również, że nulle mają interesujący wpływ na połączenia, więc ćwicz swoje lewe, prawe i pełne połączenia zewnętrzne.

Niektóre inne (choć małe) komentarze do rzucania o ścianę...

Schematy bazy danych SQL Server mogą być przydatne zarówno do organizowania tabel i procedur składowanych, jak i do kontrolowania bezpieczeństwa.

Każda tabela transakcyjna powinna zawsze śledzić zarówno kto i kiedy utworzył rekord, jak i aktualizować rekord w oddzielnych kolumnach. Widziałem implementację, która po prostu używała "daty aktualizacji", co może prowadzić do wyzwań związanych z audytem w przyszłości.

Use GUID ' s for row identyfikatory dla wszystkich wierszy dla projektów z wymaganiami offline/synchronizacji.

Dobry projekt bazy danych i normalizacja .

• tabele są nazwane w liczbie pojedynczej, małymi literami, bez podkreślników, bez prefiksu
• Pola również małe litery, bez podkreślenia, bez przedrostka
• procedury składowane poprzedzone znakiem " st_ " (sortuje ładnie)
• widoki, które są traktowane jak tabele, nie mają przedrostka
• widoki tworzone dla raportów specjalnych itp. mieć przedrostek " v "
• zindeksowane widoki stworzone dla wydajności mają przedrostek " ixv "
• wszystkie indeksy mają celowe nazwy (bez automatycznego nazewnictwa)
• zdecydowanie wolę uniqueidentifier (z przyrostem sekwencyjnym) nad tożsamością int dla kluczy zastępczych
• nie ograniczaj sztucznie pól VARCHAR/NVARCHAR do 100 lub 255. Dajcie im trochę powietrza. To nie Lata 80-te, pola nie są przechowywane na ich maksymalnej długości.
• 3NF minimum standard
• preferuje łączenie tabel z kluczami obcymi na poziomie kolumn: wiele założeń 1: m jest kwestionowanych w miarę rozwoju systemu w czasie.
• Zawsze używaj kluczy zastępczych, nie kluczy naturalnych, jako klucza podstawowego. wszystkie założenia dotyczące "naturalnych" kluczy (SSN, nazwy użytkowników, numery telefonów, kody wewnętrzne itp.) zostaną ostatecznie zakwestionowane.

Tabelaryczny sformatowany SQL.

select a.field1, b.field2
from       any_table   a
inner join blah        b on b.a_id       = a.a_id
inner join yet_another y on y.longer_key = b.b_id
where a.field_3         > 7
and   b.long_field_name < 2;

Częścią tego jest używanie jednolicie długich nazw aliasów(w przykładzie, tutaj, a, b I y są długości 1).

Z tego rodzaju formatowania, mogę szybciej odpowiedzieć na częste pytania, takie jak, " która tabela jest aliased przez 'a'?"i" które pola dołączają tabelę T do zapytania?"Zastosowanie lub aktualizacja struktury nie zajmuje dużo czasu i uważam, że oszczędza to dużo czasu. Spędzamy więcej czasu na czytaniu kodu niż na pisaniu go.

Dokumentuj wszystko; dokumentacja typu wiki jest łatwa w konfiguracji, a oprogramowanie jest bezpłatne.

Upewnij się, że najpierw rozumiesz interfejs, a następnie zaprojektujesz bazę danych. Przez większość czasu jest o wiele lepiej wiedzieć, jak dane, które zamierzasz użyć, muszą działać, a następnie zaprojektować bazę danych. Większość złego DB design dzieje się, gdy rzeczy ewoluują nie z góry.

Następnie zdefiniuj standard bazy danych i wersję, do której będziesz pracować. Definiowanie standardów dla elementów kodu (widoki, funkcje itp.), nazewnictwo baz danych; konwencje nazewnictwa kolumn, tabel; konwencje typu kolumn; szablony kodowania.

Poświęć czas na zastanowienie się, jak definiujesz typy posiadanie standardowych typów baz danych dla pól lub typów dostosowanych jest dobrą rzeczą do uporządkowania z góry.

Jako część dokumentacji Dołącz listę zakazów i dos Dla aplikacji, które zawierają preferowane przez Ciebie Kursory funkcyjne, wyzwalacze.

Przeglądaj go regularnie.

13-Oceń swoje zapytania

To prawda. Czasami nie dostajesz tego, czego chciałeś.

Dla mnie zawsze przydatne jest nazwanie tabel i pól z ich dokładną zawartością i (dla nas) w jasnym hiszpańskim i używając wielkich wielbłądów, bez białych spacji:

Nazwa Użytkownika: NombreUsuario

Imię: ApellidoPaterno

Drugie Nazwisko: ApellidoMaterno

Etc etc

Biorąc "baza danych" do znaczenia "Produkt SQL" , moja odpowiedź brzmi: "zbyt wiele, aby wspomnieć. Mógłbyś napisać całą książkę na ten temat."Szczęśliwie, ktoś to zrobił.

Używamy stylu programowania SQL Joe Celko (ISBN 978-0120887972): "ta książka jest zbiorem heurystyki i zasad, wskazówek i sztuczek, które pomogą Ci poprawić styl programowania SQL i biegłość, a do formatowania i pisania przenośnego, czytelnego, łatwego do utrzymania kodu SQL."

Zalety tego podejścia to:

• facet wie więcej o tego typu rzeczach niż ja (czy jest inna książka o heurystyce SQL?!);
• praca już została wykonana np. mogę dać książkę komuś z zespołu do przeczytania i odniesienia się do;
• jeśli komuś nie podoba się mój styl kodowania mogę winić kogoś innego;
• ostatnio dostałem masę rep NA SO polecając kolejną książkę Celko:)

W praktyce odbiegamy od zaleceń książki, ale zaskakująco rzadko.

W MS-SQL zawsze miałem obiekty należące do dbo., i prefiks wywołania do tych obiektów z dbo.

Zbyt wiele razy widziałem, jak nasi deweloperzy zastanawiają się, dlaczego nie mogą nazywać swoich obiektów, które nieumyślnie posiadali.

Unikaj głupich konwencji skrótów, takich jak obszerne słowniki skrótów, które aktywnie zachęcają do potworności, takich jak EMP_ID_CONV_FCTR_WTF_LOL_WAK_A_WAK_HU_HU. Ta zasada jest inspirowana prawdziwym zestawem wytycznych, które widziałem wcześniej.

MVP Aaron Bertrand ' s "Moja procedura składowana" najlepsze praktyki "checklist"

Nazwa tabeli pasuje do klucza głównego nazwa i klucz opisu

Tak wiem, przy linkowaniu tabel jest to dwuznaczne! Ale tak jak linkowanie ProductID do ProductID, więc uhh, po co dodatkowe typowanie?

To:

SELECT p.Name, o.Quantity FROM Products p, Orders o WHERE o.ProductID = p.ID

Jest nieco lepszy od tego:

SELECT p.Name, o.Quantity FROM Products p, Orders o WHERE o.ProductID = p.ProductID

Zauważ, że oba będą wymagały prefiksów tabeli lub aliasu. Ale nie tylko piszę nieco mniej (pomnóż to na dziesiątki tabel z długimi nazwami opisowymi i szybko się sumuje w aplikacji intensywnie wykorzystującej dane), ale także ułatwia poznanie, która tabela jest tabelą nadrzędną w każdym połączeniu, co przy łączeniu 8-10 tabel w zapytaniu może nieco pomóc.

Przestrzegam wielu tych samych konwencji, co inni tutaj, ale chciałem powiedzieć kilka rzeczy, które jeszcze nie zostały powiedziane.

Niezależnie od tego, czy lubisz nazwy w liczbie mnogiej, czy w liczbie pojedynczej, bądź spójny. Wybierz jedną lub drugą, ale nie używaj obu.

Klucz podstawowy w tabeli ma taką samą nazwę jak Tabela, z przyrostkiem _PK. Klucze obce mają taką samą nazwę jak odpowiadający im klucz podstawowy, ale z przyrostkiem _FK. Na przykład tabela produktów klucz podstawowy nazywa się Product_PK; w tabeli Order odpowiedni klucz obcy to Product_FK. Podniosłem ten nawyk od innego znajomego z DBA i jak na razie mi się podoba.

Ilekroć robię wkładkę do..SELECT, i alias wszystkie kolumny w części SELECT, aby dopasować nazwy kolumn z wstaw do części, aby ułatwić utrzymanie i zobaczyć, jak rzeczy pasują do siebie.

Najważniejszym standardem jest: domyślnie nie ma bazy danych. Znajduję zbyt wielu programistów chwytających bazę danych dla projektów, w których życie byłoby znacznie łatwiejsze bez nich (przynajmniej na razie). To tylko narzędzie w zestawie narzędzi, a nie każdy problem to gwóźdź.

Niewłaściwe użycie bazy danych prowadzi do anemicznych modeli domen, źle testowalnego kodu i niepotrzebnych problemów z wydajnością.

Zgadzam się z prawie wszystkim, co tam umieściłeś, z wyjątkiem #5. Często używam prefiksów dla tabel i procedur przechowywanych, ponieważ rozwijane przez nas systemy mają wiele różnych obszarów funkcjonalnych, więc będę miał tendencję do prefiksów tabel i zębatek z identyfikatorem, który pozwoli im ładnie grupować w Studio zarządzania w oparciu o obszar, do którego należą.

Przykład: cjso_Users, cjso_Roles, a następnie masz routing_Users, routing_Roles. Może to brzmieć jak replikacja dane, ale w rzeczywistości dwie różne tabele użytkowników / ról są dla zupełnie oddzielnych funkcji systemu (cjso byłoby dla aplikacji ecommerce opartej na kliencie, podczas gdy routing stałoby się dla pracowników i dystrybutorów, którzy korzystają z systemu routingu).

Podoba mi się nasza konwencja nazewnictwa tabeli:

People Table
PEO_PersonID
PEO_FirstName 
...

Co pomaga uczynić większe zapytania nieco bardziej czytelnymi. a jointy mają trochę więcej sensu:

Select * -- naughty!
From People
Join Orders on PEO_PersonID = ORD_PersonID
--...

Myślę, że zamiast konwencji nazewnictwa jest spójność nazewnictwa.