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

Question

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

108

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

boj 20 май 2010, в 22:01

Источник

0

Хорошо, если мы пойдем немного дальше и посмотрим на общее соглашение об именах, я настоятельно рекомендую проверить этот ответ: stackoverflow.com/questions/4702728/…
vyegorov 29 окт. 2014, в 13:21

Теги:

postgresql

naming-conventions

2 ответа

15

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

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

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

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

Основные вещи для понимания:

Если идентификаторы с двойными кавычками не сбрасываются в регистр в нижнем регистре, то MyTable, MyTable и MyTable - одно и то же, но "MYTABLE" и "MYTABLE" отличаются;
Без двойных кавычек:

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

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

Craig Ringer 16 сен. 2014, в 03:50

0

Спасибо за ссылку на документ по правилам именования идентификаторов . Мне было трудно найти эту конкретную тему.
Basil Bourque 01 апр. 2016, в 22:06

Ещё вопросы

Хорошо, если мы пойдем немного дальше и посмотрим на общее соглашение об именах, я настоятельно рекомендую проверить этот ответ: stackoverflow.com/questions/4702728/…
Спасибо за ссылку на документ по правилам именования идентификаторов . Мне было трудно найти эту конкретную тему.

leonbloy · Accepted Answer · 2010-05-21T00-32-00.000Z

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

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

Например:

UPDATE my_table SET name = 5;

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

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

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

Существуют ли какие-либо соглашения относительно ссылок на типы данных в верхнем или нижнем регистре и ссылочных функций? (т.е. regclass или REGCLASS и to_timestamp(0) или TO_TIMESTAMP(0) )? Я предполагаю, что мы рассматриваем типы и функции как идентификаторы и, следовательно, строчные буквы
FWIW, единственная особенность состоит в том, что Pg сворачивается в нижний регистр, где стандарт SQL говорит, что он должен сворачиваться в верхний регистр. СУБД, которые не в состоянии свернуть, являются странными нестандартными.
Как новый пользователь Postgres, это довольно сложно. Необходимость выбора между вводом кавычек все время или использованием уродливого соглашения об именах - отстой. Это отстой.
@ user1334007 Соглашение не безобразно - и прочитайте комментарий Крэйга выше. И нет необходимости цитировать, если вы не цитировали при создании таблиц (то есть, если вы последовательны).
@leonbloy, если вы не заключите в кавычки при создании таблицы, то Postgres будет использовать строчные буквы для имен таблиц и полей. Вы можете использовать случай верблюда, когда пишете свои запросы, но ваш результат будет отображаться в нижнем регистре, который трудно прочитать, когда поля состоят из нескольких слов (lastupdateddate). Если вы хотите, чтобы имена ваших столбцов были доступны для чтения в результатах запроса, вы должны либо заключить в кавычки все, либо использовать случай змеи, что, IMO, ужасно. Было бы намного лучше, если бы Postgres оставил ваши имена в покое и не требовал, чтобы вы указывали цитаты.
Это стандарт SQL. stackoverflow.com/questions/153944/is-sql-syntax-case-sensitive
Я ненавижу ключевые слова в верхнем регистре, просто ненавижу это, соглашение или нет. В отношении ключевых слов нет зависимости от регистра. Я предпочитаю все строчные. Да, я знаю, что это просто предпочтение, но это также простой комментарий. ;-)