Oficjalne konwencje kapitalizacji PostgreSQL [zamknięte]

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

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 .

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