Офіційні конвенції про капіталізацію PostgreSQL [закрито]

Чи існує офіційна конвенція PostreSQL щодо капіталізації в назвах БД, Таблиць і полів?

У прикладах на офіційному сайті припускають малу і _слово поділу, і мені цікаво , є чи офіційна ця політика.

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

Я в основному дзеркально зауважую коментарі Верації і констатую це, роблячи це офіційним:

Немає жодної найкращої практики, яка б охоплювала кожну обставину. Далі випливає наступне припущення (і що робити, якщо ви цього не зробили):

• Ви вже обговорювали це зі своєю командою (люди, які працюють самі, часто просто мають вирішити)
• У вашій команді вже немає формалізованого визначення стилю для SQL (інакше ви не запитуєте нас)
• Не існує формалізованого визначення стилю для будь-якого коду (Дотримуйтесь тих самих основних умов, які вже були встановлені для інших мов, і формалізуйте стиль)

Тож решта цього дещо впевнено, але заснована на досвіді

1. Якщо мова йде про назви таблиць
   1. Вам слід вказувати особливі назви юридичних осіб (це полегшує документацію)
   2. Тут слід скористатися Паскальним кейсом
2. Якщо мова йде про назви полів
   1. Використовуйте camelCase у своїх назвах полів
   2. Використовуйте короткі однинні імена, якщо тільки визначення не має сенсу як множини (це майже ніколи)
3. Якщо мова йде про вашу власну функцію або збережені назви процедур
   1. Використовуйте підкреслення_сепарації
   2. Використовуйте найменування поля для параметризації
4. Якщо мова йде про вбудовані функції баз даних або назви мов (наприклад, SELECT)
   1. Якщо немає вимоги, щоб вона була використана з великої літери, використовуйте ВСІ КАПС
   2. Знайте API для своєї мови, щоб зрозуміти, що розумно чи потрібно
5. Якщо мова йде про інтервали
   1. Багато людей використовують вирівнювання стовпців для ключових слів і відступ для речей, які не є ключовими словами
   2. Дуже багато людей використовують коми на початку рядка, коли поля розділені в кожному рядку (Це полегшує коментування певного поля зі списку вибору)
   3. Ніколи не використовуйте пробіли як частину назв речей, навіть не для заголовків зворотного значення.
6. Коли мова йде про розділові знаки
   1. Дужки - ВИКОРИСТОВУЙТЕ ЇХ. Вони БЕЗКОШТОВНІ. Я обіцяю.
   2. Крапки з комою - ВИКОРИСТОВУЙТЕ ЇХ. Вони не збираються тебе ламати. Вони змушують вас придумати свій код. І вони дотримуються хорошої гігієни.
   3. Повернення перевезення - ще раз вони безкоштовні ;-) І зробіть ваш код читабельним.

Ви також повинні визнати, що, хоча я намагаюся допомогти вам застосувати загальний посібник зі стилів, спільнота для Postgres зазвичай не використовує camelCase або PascalCase, а натомість використовує underscore_separation. Дійсно важливий біт є забезпечити , щоб ви встановити і використовувати стиль конкретної всюди бути послідовним .

Швидкий Google виявить багато сайтів, які вказують на найкращі практики. Я б сказав лише дві речі - НІКОЛИ не використовуйте пробілів "Ім'я моєї таблиці" (перенесення стає неможливим через різні механізми пропуску; те ж саме стосується будь-яких буквено-цифрових символів). З такими різними механізмами, як правило, ви також повинні поважати справи. В англійській (або вашій власній) мові достатньо букв і слів, а довжина ідентифікатора досить довга (я не знаю жодної системи, яка має ідентифікатор_ довжина <32, PostgreSQL - 64). І ніколи не використовуйте ключові слова SQL (які залежать від RDBMS), які будуть робити те саме.

Плаценти, як

SELECT "Field" FROM "Table";

може бути дійсним! Абсолютно критична річ - мати чітку і відносно просту конвенцію, а потім дотримуватися її. Як ви дізнаєтесь, люди мають різні думки - читайте навколо теми і вибирайте те, що «вам належить». Перегляньте ці сайти 1 , 2 , 3 , 4 , 5 , ... (є ще багато).