1. дома
  2. Вопрос и ответ
  3. Есть ли соглашение об именах для MySQL?

Есть ли соглашение об именах для MySQL?

2011-10-26 3 views
109

Вот как я это делаю:Есть ли соглашение об именах для MySQL?

  1. имена таблиц в нижнем регистре, использует подчеркивания для разделения слов, и являются особыми (например, «Foo», «foo_bar» и т.д.
  2. я обычно (не всегда) имеют auto increment PK. Я использую следующее соглашение: tablename_id (например, «foo_id», «foo_bar_id» и т. д.).
  3. Когда таблица содержит столбец, являющийся внешним ключом, я просто копирую имя столбца этого ключ из любой таблицы, из которой он пришел. Например, таблица table 'foo_bar' имеет FK 'foo_id' (где 'foo_id' является PK из 'foo').
  4. При определении FK для enfo rce референциальная целостность, я использую следующее: tablename_fk_columnname (например, в соответствии с примером 3 это будет «foo_bar_foo_id»). Поскольку это комбинация имен таблиц/столбцов, она гарантирована быть уникальной в базе данных.
  5. Приказываю столбцы, как это: ПКС, ФКС, то остальная часть колонн по алфавиту

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

источник

2011-10-26 StackOverflowNewbie

+3

Неправильно использовать для автоматического увеличения PK jus t "id"? Зачем? Имя столбца имеет смысл только в контексте таблицы. Поэтому у меня есть один «id» в каждой таблице и может иметь много id_ для FK. – Zbyszek

+1

@Zbyszek Я думаю, что простейшая причина в том, что это просто для согласованности/простоты. Вместо того, чтобы иметь 'id_tableB' => * oh no * ** столбцы с разными именами **' id', согласованность 'id_tableB' =>' id_tableB' просто выглядит более аккуратно ... или как OP делает это: 'foo_id' => 'foo_id', а не' foo_id' => 'id' – mmcrae

ответ

77

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

Я считаю, что вы почти там с условностями, которые вы изложили в своем вопросе. Несколько комментариев:

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

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

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

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

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

Индекс соглашения об именах

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

болванка против Plural имена столбцов

Это может быть хорошей идеей, чтобы решить сложную проблему множественного числа против синглом в именах столбцов, а также ваше имя (ы) таблицы. Этот вопрос часто вызывает big debates в сообществе DB. Я бы придерживался сингулярных форм для имен таблиц и столбцов. Там. Я это сказал.

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

источник

2011-10-26 07:09:23

+0

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

+4

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

+0

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

5

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

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

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

PS: Лично я думаю, 5) является излишеством ...

источник

2011-10-26 06:11:27 paulsm4

+1

Далеко от того, чтобы быть фанатиками, случай с верблюдом на самом деле нахмурился многими сообществами БД, потому что некоторые из РСУБД нечувствительны к регистру, (или изменить все на верхний регистр), поэтому все становится действительно уродливым очень быстро. – mwan

+0

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

+2

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

14

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

Стандарт сам по себе является личным предпочтением - поэтому, если вам нравится ваш стандарт, а затем бегите с ним.

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

источник

2011-10-26 06:16:01 mwan

Смежные вопросы

 Смежные вопросы