Существует ли соглашение об именах для MySQL?


163

Вот как я это делаю:

  1. Имена таблиц в нижнем регистре, используются подчеркивания для разделения слов и в единственном числе (например foo, foo_barи т. Д.)
  2. У меня вообще (не всегда) есть автоприращение ПК. Я использую следующее соглашение: tablename_id(например foo_id, foo_bar_idи т. Д.).
  3. Когда таблица содержит столбец, который является внешним ключом, я просто копирую имя столбца этого ключа из любой таблицы, из которой он получен. Например, скажем, таблица foo_barимеет FK foo_id(где foo_idPK foo).
  4. При определении FK для обеспечения ссылочной целостности, я использую следующее: tablename_fk_columnname(например, продолжая пример 3, это будет foo_bar_foo_id). Поскольку это комбинация имени таблицы / имени столбца, она гарантированно будет уникальной в базе данных.
  5. Я упорядочиваю столбцы так: PK, FK, а затем остальные столбцы в алфавитном порядке.

Есть ли лучший, более стандартный способ сделать это?


6
Неправильно ли использовать для автоматического приращения PK просто «id»? Зачем? Имя столбца имеет значение только в контексте таблицы. Таким образом, у меня есть один «идентификатор» в каждой таблице, и может быть много id_ <table_name> для FK.
Збышек

3
@Zbyszek Я думаю, что самая простая причина против этого - просто последовательность / простота. Вместо того, чтобы иметь id_tableB=> о, нет никакого другого имени столбца id , последовательность id_tableB=> id_tableBпросто выглядит аккуратнее ... или, как это делает OP: foo_id=> foo_idа не foo_id=>id
Дон Чидл

Ответы:


106

Я бы сказал, что в первую очередь: будьте последовательны.

Я считаю, что вы почти пришли к соглашению, которое вы изложили в своем вопросе. Пара комментариев, хотя:

Точки 1 и 2 хороши, я считаю.

Пункт 3 - к сожалению, это не всегда возможно. Подумайте, как бы вы справились с одной таблицей, в foo_barкоторой есть столбцы, foo_idи another_foo_idобе из которых ссылаются на столбец fooтаблицы foo_id. Вы можете подумать, как справиться с этим. Это немного угловой случай, хотя!

Пункт 4 - аналогичен пункту 3. Возможно, вы захотите ввести число в конце имени внешнего ключа, чтобы обеспечить наличие более одного ссылочного столбца.

Пункт 5 - я бы этого избежал. Это дает вам мало и станет головной болью, когда вы захотите добавить или удалить столбцы из таблицы позже.

Некоторые другие моменты:

Соглашения об именовании индексов

Возможно, вы захотите ввести соглашение об именовании для индексов - это будет очень полезно для любой работы с метаданными базы данных, которую вы, возможно, захотите выполнить. Например, вы можете просто захотеть вызвать индекс foo_bar_idx1или foo_idx1- полностью на ваше усмотрение, но стоит подумать.

Сингулярные и множественные имена столбцов

Это может быть хорошей идеей для решения сложной проблемы множественного числа против одиночного в именах столбцов, а также в именах таблиц. Эта тема часто вызывает большие дебаты в сообществе БД. Я бы придерживался форм единственного числа для имен таблиц и столбцов. Там. Я это сказал.

Главное здесь, конечно, последовательность!


Что было бы лучше, чем пункт 5? Почему это может стать головной болью?
Расшу

8
Чтобы продолжить, я нашел эту версию полезной для тех, кто придет сюда позже: launchbylunch.com/posts/2014/Feb/16/sql-naming-conventions/…
Enissay

1
У меня возникают проблемы с поиском хорошей «схемы» для именования моих таблиц, которые содержат объекты моделей, состоящие из двух имен (DocumentChapter, DocumentVersion, DocumentType и т. Д.). Например, для DocumentType я мог бы назвать его documenttypeили document_type. Я бы предпочел последний, но в большинстве случаев у меня есть отношения многие ко многим, и мне нужен стол, похожий на document_document_type. Любые предложения, как справиться с этим?
Лексит

@ rsb2097 Re: точка 5 - После добавления одного столбца (до конца) ордер может стать недействительным. Не следует добавлять какие-либо ограничения, которые требуют переупорядочения столбцов, так как это ненужные накладные расходы.
Уилл Шеппард

21

Согласованность является ключом к любому стандарту именования. Пока это логично и последовательно, вы там на 99%.

Сам стандарт - очень личное предпочтение - так что, если вам нравится ваш стандарт, то используйте его.

Чтобы ответить на ваш вопрос прямо - нет, MySQL не имеет предпочтительного соглашения / стандарта именования, так что переходить на ваш вариант - это хорошо (и ваш кажется логичным).


8

MySQL имеет краткое описание их более или менее строгих правил:

https://dev.mysql.com/doc/internals/en/coding-style.html

Наиболее распространенный стиль кодирования для MySQL от Simon Holywell:

http://www.sqlstyle.guide/

См. Также этот вопрос: существуют ли опубликованные рекомендации по стилю кодирования для SQL?


4

К счастью, разработчики PHP не такие «фанаты верблюдов», как некоторые сообщества разработчиков, которых я знаю.

Ваши соглашения звучат хорошо.

Пока они а) просты и б) последовательны - я не вижу проблем :)

PS: Лично я думаю 5) это перебор ...


2
Отнюдь не фанатики, на многих верблюжьих не одобряют верблюжий случай, потому что некоторые СУБД нечувствительны к регистру до такой степени, что они разбирают дела (или изменяют все на верхний регистр), так что все становится действительно ужасно быстро.
Мал-Ван

@mwan: можете ли вы указать, какая СУБД? И я сам жокей на верблюжьей шкуре. Заглавные буквы служат только одной цели в моей схеме: указывать таблицы соединений и (в случае полей) указывать границы слов, так что _ может быть исключительно для обозначения othertable_id (т. Е. Имя таблицы = othertable и поле в этой таблице = id ). Кроме того, если другая СУБД нечувствительна к регистру, какое это имеет значение? Я никогда не собираюсь использовать заглавные и строчные версии одной и той же таблицы! О, и я бы не предпочел РСУБД без учета регистра - я бы предпочел написать непротиворечивый код
Сэмюэль Фулман

7
Мне нравится ирония пользователей MySQL, которым не нравятся CamelCase и название продукта, который мы используем: MySQL, написанный на CamelCase
DBX12

1
@ DBX12 Чтобы быть педантичным, это PascalCase, а не camelCase, но ваша точка зрения остается в силе.
MarredCheese

@MarredCheese Никогда не думал об этом, но ты прав. У camelCase не должно быть горба на старте.
DBX12

1

Простой ответ: НЕТ

Ну, по крайней мере, соглашение об именах, как таковое, поощряемое Oracle или сообществом, нет, однако, в основном вы должны знать о соблюдении правил и ограничений для идентификаторов, как указано в документации MySQL: https://dev.mysql.com /doc/refman/8.0/en/identifiers.html

Что касается соглашения об именах, которому вы следуете, я думаю, что это нормально, просто число 5 немного излишне, я думаю, что большинство визуальных инструментов для управления базами данных предлагают опцию для сортировки имен столбцов (я использую DBeaver, и он есть), поэтому если у purpouse хорошая визуальная презентация вашего стола, вы можете использовать эту опцию, которую я упоминаю.

По личному опыту я бы порекомендовал это:

  • Используйте нижний регистр . Это практически обеспечивает совместимость при переносе баз данных с одного сервера на другой. Иногда lower_case_table_namesон неправильно настроен, и ваш сервер начинает выдавать ошибки, просто не распознавая ваш стандарт camelCase или PascalCase (проблема чувствительности к регистру).
  • Короткие имена . Просто и понятно. Чем проще и быстрее определить вашу таблицу или столбцы, тем лучше. Поверьте мне, когда вы делаете много разных запросов за короткий промежуток времени, лучше, когда все просто написать (и прочитать).
  • Избегайте префиксов . Если вы не используете одну и ту же базу данных для таблиц разных приложений, не используйте префиксы. Это только добавляет больше подробности к вашим запросам. Существуют ситуации, когда это может быть полезно, например, когда вы хотите идентифицировать первичные ключи и внешние ключи, обычно имена таблиц используются в качестве префикса для столбцов идентификаторов.
  • Используйте подчеркивание для разделения слов . Если вы по-прежнему хотите использовать более одного слова для именования таблицы, столбца и т. Д., Так что используйте подчеркивание для разделения_the_words , это помогает для разборчивости (ваши глаза и ваш напряженный мозг будут вам благодарны).
  • Будьте последовательны . Если у вас есть свой собственный стандарт, следуйте ему. Не будь человеком, который создает правила и первым нарушает их, это позорно.

А как насчет именования "Plural vs Singular"? Ну, это в основном ситуация личных предпочтений. В моем случае я пытаюсь использовать множественные имена для таблиц, потому что я думаю, что таблица - это совокупность элементов или пакет, содержащий элементы, поэтому имя во множественном числе имеет смысл для меня; и уникальные имена для столбцов, потому что я вижу столбцы как атрибуты, которые описывают эти элементы таблицы в единственном числе.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.