Соглашения об именах PostgreSQL

Где я могу найти подробное руководство по соглашениям об именах PostgreSQL? (имена таблиц и регистр верблюдов, последовательности, первичные ключи, ограничения, индексы и т. д.)

Источник

3 ответа

Решение

Что касается имен таблиц, регистра и т. Д., Распространенное соглашение:

  • Ключевые слова SQL: UPPER CASE
  • имена (идентификаторы): lower_case_with_underscores

Например:

UPDATE my_table SET name = 5;

Это не написано в камне, но бит об идентификаторах в нижнем регистре настоятельно рекомендуется, IMO. Postgresql обрабатывает идентификаторы без учета регистра, когда они не заключены в кавычки (он фактически сворачивает их в нижний регистр внутри), и с учетом регистра при цитировании; многие люди не знают об этой идиосинкразии. Используя всегда строчные буквы, вы в безопасности. Во всяком случае, это приемлемо для использования camelCase или же PascalCase (или же UPPER_CASE), если вы последовательны: либо всегда указывайте идентификаторы, либо никогда (и это включает создание схемы!).

Я не знаю о многих других соглашениях или руководствах по стилю. Суррогатные ключи обычно создаются из последовательности (обычно с serial макрос), было бы удобно придерживаться этого имени для этих последовательностей, если вы создаете их вручную (tablename_colname_seq).

Смотрите также некоторые обсуждения здесь, здесь и (для общего SQL) здесь, все с несколькими связанными ссылками.

Источник

Нет действительно формального руководства, потому что нет единого стиля или стандарта.

Пока вы понимаете правила именования идентификаторов, вы можете использовать все, что захотите.

На практике мне легче пользоваться lower_case_underscore_separated_identifiers потому что нет необходимости "Double Quote" их везде, чтобы сохранить случай, пробелы и т. д.

Если вы хотите назвать ваши таблицы и функции "@MyAṕṕ! ""betty"" Shard$42" ты был бы свободен сделать это, хотя было бы больно печатать везде.

Основные вещи, которые нужно понять:

  • Если в двойных кавычках идентификаторы не преобразуются в нижний регистр, MyTable, MYTABLE а также mytable все одно и то же, но "MYTABLE" а также "MyTable" разные;

  • Если не указано в двойных кавычках:

    Идентификаторы SQL и ключевые слова должны начинаться с буквы (az, но также буквы с диакритическими знаками и нелатинскими буквами) или подчеркивания (_). Последующие символы в идентификаторе или ключевом слове могут быть буквами, подчеркиванием, цифрами (0-9) или знаками доллара ($).

  • Вы должны заключить в кавычки ключевые слова, если хотите использовать их в качестве идентификаторов.

На практике я настоятельно рекомендую не использовать ключевые слова в качестве идентификаторов. По крайней мере, избегайте зарезервированных слов. Просто потому, что вы можете назвать таблицу "with" не значит, что ты должен

Источник

Единственными двумя ответами здесь являются 6-летние idk, если змеиный случай, являющийся лучшим случаем, больше не является правдой. Вот мой взгляд на современность. Кроме того, отказ от любых дополнительных осложнений, связанных с необходимостью двойных кавычек. Я думаю, что поток важнее, чем попытки избежать незначительных неудобств.

Учитывая тот факт, что нет строгих руководств/руководств по стилю, я бы сказал, что лучше всего использовать тот же случай, что и код проекта. Так, например, при использовании подхода ООП в таких языках, как JavaScript, имена таблиц будут в PascalCase, а атрибуты — в camelCase. Где, как если бы вы использовали функциональный подход, они оба были бы camelCase. Кроме того, по соглашению JS-классы имеют формат PascalCase, а атрибуты — camelCase, так что в любом случае это имеет смысл.

С другой стороны, если вы программируете на Python с использованием SqlAlchemy, имеет смысл использовать только имена в змеином регистре для моделей, производных от функций, и имена PascalCase для моделей, производных от классов. В обоих случаях атрибуты/столбцы должны быть змеиными.

Источник
Другие вопросы по тегам