Официальные соглашения о капитализации PostgreSQL [закрыто]

14

Существует ли официальное соглашение 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
);
Адам Матан
источник
1
Проверьте также эту часть документации, об идентификаторах
ypercubeᵀᴹ

Ответы:

20

Я собираюсь в основном отразить комментарии Вераса и заявить об этом, сделав его полуофициальным:

Не существует единой наилучшей практики , которая охватила бы все обстоятельства. Далее следует следующие предположения (и что делать, если вы этого не сделали):

  • Вы уже обсуждали это со своей командой (люди, работающие сами по себе, часто просто должны решить)
  • В вашей команде нет формализованного определения стиля для SQL (иначе вы бы не спросили нас)
  • Для любого кода не существует формализованного определения стиля (следуйте тем же базовым соглашениям, которые уже установлены для других языков, и формализуйте стиль)

Таким образом, остальное это несколько самоуверенно, но на основе опыта

  1. Когда дело доходит до имен таблиц
    1. Вы должны использовать отдельные имена сущностей (это облегчает документирование)
    2. Вы должны использовать Pascal Case здесь
  2. Когда дело доходит до имен полей
    1. Используйте camelCase в именах полей
    2. Используйте короткие имена в единственном числе, если определение не имеет смысла во множественном числе (почти никогда не имеет)
  3. Когда дело доходит до ваших собственных функций или имен хранимых процедур
    1. Используйте underscore_separation
    2. Используйте именование полей для параметризации
  4. Когда дело доходит до встроенных функций базы данных или имен языков (например, SELECT)
    1. Если не требуется, чтобы он был написан заглавными буквами определенным образом, используйте ALL CAPS
    2. Знать API для вашего языка, чтобы знать, что разумно или требуется
  5. Когда дело доходит до расстояния
    1. Многие люди используют выравнивание столбцов для ключевых слов и отступ для вещей, которые не являются ключевыми словами
    2. Многие люди используют запятые в начале строки, когда поля разделены в каждой строке (это позволяет легче закомментировать определенное поле из списка выбора)
    3. Никогда не используйте пробелы как часть имен вещей, даже для заголовков возвращаемых значений.
  6. Когда дело доходит до пунктуации
    1. Скобки - ИСПОЛЬЗУЙТЕ ИХ. Они БЕСПЛАТНЫЕ. Я обещаю.
    2. Точки с запятой - ИСПОЛЬЗУЙТЕ ИХ. Они не собираются тебя сломать. Они заставляют вас придумывать свой код. И они хорошая гигиена.
    3. Возврат каретки - опять же, они бесплатны ;-) и делают ваш код читабельным.

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

jcolebrand
источник
3
+1 за «Действительно важный бит - это убедиться, что вы устанавливаете и используете определенный стиль везде, чтобы быть последовательными». Последовательность является ключом. Без этого вам придется думать о вещах, о которых вы никогда не должны думать.
Макс Вернон
4
Ну, camelCase и PascalCase в PostgreSQL немного болезненны. Вы должны процитировать их, если вы действительно хотите, чтобы такие имена были такими, в противном случае система беззвучно вводит их в нижнем регистре (я чуть не написал декапитализацию, какие бы ассоциации она не вызывала).
Дезсо
А как насчет имен баз данных? Должен ли я использовать database_name, database-name, DatabaseName,databaseName и т.д.?
ma11hew28
1
Этот ответ на самом деле для PostgreSQL? Если вы дадите совет использовать PascalCase для имен таблиц в специфичном для PG ответе, я думаю, вы должны упомянуть (а) как справиться с тем фактом, что в большинстве примеров используются строчные ключевые слова, и (б) указывать в кавычках имена таблиц или разрешать PG сложите их в нижний регистр.
AndreKR
@AndreKR вот в чем дело: я ожидаю, что разработчики программного обеспечения будут взрослыми, уметь читать документацию и обсуждать со своей командой, как правильно писать код. Этот ответ - вики сообщества, означающий, что каждый может редактировать и улучшать его. Я не могу точно сказать «это единственный путь», и то, что некоторые люди приводят примеры в нижнем регистре, не означает, что это единственный путь в жизни. Ты должен найти свой собственный путь, который был духом этого ответа. Пожалуйста, не стесняйтесь редактировать этот ответ сообщества, чтобы улучшить его. Благодарность!
Jcolebrand
4

Быстрый Google покажет много сайтов, которые указывают на лучшие практики. Я бы сказал только две вещи - НИКОГДА не используйте пробелы «Имя моей таблицы» (перенос становится невозможным из-за различных механизмов экранирования; то же самое касается любого не алфавитно-цифрового символа). С такими видами механизмов вы обычно должны уважать случай. В английском (или вашем собственном) языке достаточно букв и слов, а длина идентификаторов достаточно велика (я не знаю ни одной системы, у которой identifier_length <32, PostgreSQL равен 64). И никогда не используйте ключевые слова SQL (которые зависят от СУБД), которые будут делать то же самое.

Уставы как

SELECT "Field" FROM "Table";

может быть действительным! Абсолютно критическая вещь - иметь четкое и относительно простое соглашение, а затем придерживаться его. Как вы узнаете, у людей разные мнения - прочитайте тему и выберите то, что вам кажется правильным. Смотрите эти сайты 1 , 2 , 3 , 4 , 5 , ... (есть еще много).

Verace
источник
Спасибо, я наткнулся на многих в моих собственных поисках. Я хотел знать, есть ли какой-нибудь официальный стайл гид.
Адам Матан
С обеих сторон дискуссии (singular_table_name / множественное_имя_таблицы) есть много практикующих, чье мнение о других областях я уважаю. Я сам "одинокий" человек - если вы управляете атомной электростанцией, у вас может быть таблица с именем catastrophic_meltdown, в которой вы вообще не хотите видеть никаких записей! Дайте вашим первичным ключам суффикс _id и обозначьте их как Parent_Table_Name_FK в дочерних таблицах - это то, что я делаю. После этого легко-peasy! Что касается caps / no-caps, мои сценарии SQL имеют верблюжий регистр (без кавычек), мои утверждения могут или не могут.
Верас