Oficjalne konwencje kapitalizacji PostgreSQL [zamknięte]

14

Czy istnieje oficjalna konwencja PostreSQL dotycząca wielkich liter w nazwach DB, tabel i pól?

Te przykłady na oficjalnej stronie wskazują na małą i _słowo separację, i zastanawiam się, czy ta polityka jest urzędnik.

CREATE TABLE films (
    code        char(5) CONSTRAINT firstkey PRIMARY KEY,
    title       varchar(40) NOT NULL,
    did         integer NOT NULL,
    date_prod   date,
    kind        varchar(10),
    len         interval hour to minute
);
Adam Matan
źródło
1
Sprawdź również tę część dokumentacji na temat identyfikatorów
ypercubeᵀᴹ

Odpowiedzi:

20

Zasadniczo zamierzam odzwierciedlić komentarze Verace i podać to, czyniąc to półoficjalnym:

Nie ma jednej najlepszej praktyki , która obejmowałaby każdą okoliczność. Poniżej przedstawiono następujące założenia (i co zrobić, jeśli tego nie zrobiłeś):

  • Rozmawiałeś już o tym ze swoim zespołem (ludzie, którzy pracują sami, często muszą się zdecydować)
  • W twoim zespole nie ma sformalizowanej definicji stylu SQL (w przeciwnym razie nie pytasz nas)
  • Nie ma sformalizowanej definicji stylu dla żadnego kodu (Postępuj zgodnie z tymi samymi podstawowymi konwencjami, które zostały już ustanowione dla innych języków i sformalizuj styl)

Reszta jest nieco opiniotwórcza, ale oparta na doświadczeniu

  1. Jeśli chodzi o nazwy tabel
    1. Powinieneś wybrać pojedynczą nazwę encji (ułatwia to dokumentację)
    2. Powinieneś użyć tutaj Pascal Case
  2. Jeśli chodzi o nazwy pól
    1. Użyj camelCase na swoich nazwach pól
    2. Używaj krótkich pojedynczych nazw, chyba że definicja zdecydowanie ma sens jako liczba mnoga (prawie nigdy tak nie jest)
  3. Jeśli chodzi o nazwy własnych funkcji lub procedur składowanych
    1. Użyj separacji podkreślenia
    2. Użyj parametryzacji do nazewnictwa pól
  4. Jeśli chodzi o wbudowane funkcje bazy danych lub nazwy języków (np. SELECT)
    1. O ile nie jest wymagane, aby była ona pisana wielkimi literami, użyj WSZYSTKICH KAPITÓW
    2. Poznaj interfejsy API dla swojego języka, aby wiedzieć, co jest uzasadnione lub wymagane
  5. Jeśli chodzi o odstępy
    1. Wielu ludzi używa wyrównywania kolumn dla słów kluczowych i wcięcia dla rzeczy, które nie są słowami kluczowymi
    2. Wielu ludzi używa przecinków na początku wiersza, gdy pola są oddzielone w każdym wierszu (ułatwia to komentowanie określonego pola z listy wyboru)
    3. Nigdy nie używaj spacji jako części nazw rzeczy, nawet w przypadku nagłówków wartości zwracanych.
  6. Jeśli chodzi o interpunkcję
    1. Nawiasy - UŻYWAJ JE. Są BEZPŁATNE. Obiecuję.
    2. Średniki - WYKORZYSTAJ JE. Nie zamierzają cię złamać. Zmuszają cię do przemyślenia swojego kodu. I są dobrej higieny.
    3. Powóz powraca - po raz kolejny są bezpłatne ;-) I spraw, aby Twój kod był czytelny.

Powinieneś także wiedzieć, że podczas gdy próbuję pomóc Ci zastosować ogólny przewodnik po stylu, społeczność Postgres zasadniczo nie używa camelCase ani PascalCase, ale zamiast tego używa underscore_separation. Naprawdę ważne bit jest zapewnienie, że wprowadzenie i stosowanie specyficznego stylu wszędzie być spójne .

jcolebrand
źródło
3
+1 za „Naprawdę ważne jest, aby ustanowić i stosować określony styl wszędzie, aby zachować spójność”. Spójność jest kluczem. Bez tego musisz myśleć o rzeczach, o których nigdy nie powinieneś myśleć.
Max Vernon
4
Cóż, camelCase i PascalCase w PostgreSQL są nieco bolesne. Musisz je zacytować, jeśli naprawdę chcesz mieć takie nazwy, w przeciwnym razie system po cichu je małymi literami (prawie napisałem dekapitalizację, niezależnie od skojarzeń, jakie może to wywołać).
dezso
Co z nazwami baz danych? Powinno się używać database_name, database-name, DatabaseName, databaseName, itd.?
ma11hew28,
1
Czy ta odpowiedź faktycznie dotyczy PostgreSQL? Jeśli dajesz radę używania PascalCase do nazw tabel w odpowiedzi specyficznej dla PG, myślę, że powinieneś wspomnieć (a) jak poradzić sobie z faktem, że większość przykładów używa małych słów kluczowych i (b) czy cytować nazwy tabel, czy pozwolić PG złóż je na małe litery.
AndreKR
@AndreKR o to chodzi: oczekuję, że twórcy oprogramowania będą pełnoletni, będą umieli czytać dokumentację i dyskutować ze swoim zespołem, jak konsekwentnie pisać kod. Ta odpowiedź to wiki społeczności, co oznacza, że ​​każdy może ją edytować i ulepszać. Nie mogę powiedzieć dokładnie „to jest jedyny sposób”, a to, że niektórzy ludzie podają przykłady małymi literami, nie oznacza, że ​​jest to jedyny sposób w życiu. Musisz znaleźć własną ścieżkę, która była duchem tej odpowiedzi. Edytuj tę odpowiedź społeczności, aby ją poprawić. Dzięki!
jcolebrand
4

Szybkie Google ujawni wiele witryn wskazujących najlepsze praktyki. Powiedziałbym tylko dwie rzeczy - NIGDY nie używaj spacji „My Table Name” (przenoszenie staje się niemożliwe z powodu różnych mechanizmów zmiany znaczenia; to samo dotyczy znaków innych niż alfanumeryczne). Przy tego rodzaju mechanimach normalnie musisz także szanować wielkość liter. W języku angielskim (lub twoim własnym) jest wystarczająco dużo liter i słów, a długości identyfikatorów są wystarczająco długie (nie znam żadnego systemu, który ma identyfikator_długości <32, PostgreSQL to 64). I nigdy nie używaj słów kluczowych SQL (które różnią się w zależności od RDBMS), które zrobią to samo.

Oświadczenia takie jak

SELECT "Field" FROM "Table";

może być ważny! Absolutnie krytyczną rzeczą jest stworzenie jasnej i stosunkowo prostej konwencji, a następnie trzymanie się jej. Ludzie mają różne opinie, jak się dowiesz - przeczytaj ten temat i wybierz to, co „pasuje ci”. Zobacz te strony 1 , 2 , 3 , 4 , 5 , ... (jest ich znacznie więcej).

Vérace
źródło
Dzięki, natknąłem się na wielu podczas moich własnych poszukiwań. Chciałem wiedzieć, czy jest jakiś oficjalny przewodnik po stylach.
Adam Matan
Po obu stronach debaty (nazwa_tabularna / nazwa_turalna_pl) występuje wielu praktyków, których opinie w innych obszarach szanuję. Sam jestem „samotnym” człowiekiem - jeśli prowadzisz elektrownię jądrową, możesz mieć tabelę o nazwie katastrofa_zgłoszenia, w której nigdy nie chcesz widzieć żadnych zapisów! Daj swoim kluczom podstawowym sufiks _id i nazywaj je jako Parent_Table_Name_FK w tabelach potomnych - to właśnie robię. Po tym wszystko jest łatwe! Jeśli chodzi o caps / no-caps, moje skrypty SQL mają wielbłądy (bez cudzysłowu), moje instrukcje mogą, ale nie muszą.
Vérace