Схема именования иностранных ключей
Я только начинаю работать с внешними ключами в первый раз, и мне интересно, есть ли у них стандартная схема именования?
Учитывая эти таблицы:
task (id, userid, title)
note (id, taskid, userid, note);
user (id, name)
В тех случаях, когда задачи имеют заметки, задачи принадлежат Пользователям и Заметкам пользователей Notes.
Как можно было бы назвать три внешних ключа в этой ситуации? Или, наоборот, это вообще имеет значение?
Обновление: этот вопрос касается имен внешних ключей, а не имен полей!
Ответы
Ответ 1
Стандартное соглашение в SQL Server:
FK_ForeignKeyTable_PrimaryKeyTable
Итак, например, ключ между примечаниями и задачами будет:
FK_note_task
И ключ между задачами и пользователями будет:
FK_task_user
Это дает вам "на первый взгляд" вид, какие таблицы задействованы в ключе, поэтому он позволяет легко видеть, какие таблицы являются определенными (первый из них), зависит от (второго названного). В этом случае полный набор ключей будет:
FK_task_user
FK_note_task
FK_note_user
Таким образом, вы можете видеть, что задачи зависят от пользователей, а заметки зависят от обеих задач и пользователей.
Ответ 2
Я использую два символа подчеркивания как разделитель, т.е.
fk__ForeignKeyTable__PrimaryKeyTable
Это связано с тем, что имена таблиц иногда содержат символы подчеркивания. Это следует за соглашением об именах для ограничений, поскольку имена элементов данных часто содержат символы подчеркивания, например.
CREATE TABLE NaturalPersons (
...
person_death_date DATETIME,
person_death_reason VARCHAR(30)
CONSTRAINT person_death_reason__not_zero_length
CHECK (DATALENGTH(person_death_reason) > 0),
CONSTRAINT person_death_date__person_death_reason__interaction
CHECK ((person_death_date IS NULL AND person_death_reason IS NULL)
OR (person_death_date IS NOT NULL AND person_death_reason IS NOT NULL))
...
Ответ 3
Как насчет FK_TABLENAME_COLUMNNAME
?
K eep I t S imple S tupid, когда это возможно.
Ответ 4
Обычно я просто оставляю свой PK с именем id, а затем объединяю имя таблицы и имя столбца при именах FK в других таблицах. Я никогда не беспокоюсь о верблюжьей оболочке, потому что некоторые базы данных отбрасывают чувствительность к регистру и просто возвращают все имена верхнего или нижнего регистра в любом случае. В любом случае, вот как выглядит моя версия ваших таблиц:
task (id, userid, title);
note (id, taskid, userid, note);
user (id, name);
Обратите внимание, что я также называю мои таблицы в единственном числе, потому что строка представляет один из объектов, которые я сохраняю. Многие из этих конвенций являются личными предпочтениями. Я бы предположил, что более важно выбирать конвенцию и всегда использовать ее, а не принимать другое соглашение.
Ответ 5
Заметка от Microsoft относительно SQL Server:
Ограничение FOREIGN KEY не обязательно должно быть связано только с PRIMARY Ограничение KEY в другой таблице; его также можно определить для ссылки столбцы ограничения UNIQUE в другой таблице.
поэтому я буду использовать термины, описывающие зависимость, а не обычные условия первичной/внешней связи.
При ссылке на PRIMARY KEY независимой (родительской) таблицы на столбцы с аналогичным именем в зависимой (дочерней) таблице я опускаю имена столбцов:
FK_ChildTable_ParentTable
При ссылке на другие столбцы или имена столбцов различаются между двумя таблицами или просто для явного:
FK_ChildTable_childColumn_ParentTable_parentColumn
Ответ 6
Мой обычный подход
FK_ColumnNameOfForeignKey_TableNameOfReference_ColumnNameOfReference
Или в других терминах
FK_ChildColumnName_ParentTableName_ParentColumnName
Таким образом, я могу назвать два внешних ключа, которые ссылаются на ту же таблицу, что и history_info table
на column actionBy and actionTo
из users_info
table
Это будет как
FK_actionBy_usersInfo_name - For actionBy
FK_actionTo_usersInfo_name - For actionTo
Обратите внимание:
Я не включил имя дочерней таблицы, потому что это кажется мне здравым смыслом, я в таблице этого ребенка, поэтому я могу легко предположить имя дочерней таблицы. Общий характер его 26 и хорошо подходит для 30-символьного предела оракула, о котором заявил Чарльз Бернс в комментарии здесь p >
Примечание для читателей: многие из передовых методов, перечисленных ниже, не работают в Oracle из-за его 30-символьного ограничения имен. Имя таблицы или имя столбца может быть уже около 30 символов, поэтому соглашение объединение двух в одно имя требует стандартного усечения или другие трюки. - Чарльз Бернс
Ответ 7
Это, вероятно, слишком много, но это работает для меня. Это очень помогает мне, особенно когда я имею дело с VLDB. Я использую следующее:
CONSTRAINT [FK_ChildTableName_ChildColName_ParentTableName_PrimaryKeyColName]
Конечно, если по какой-то причине вы не ссылаетесь на первичный ключ, вы должны ссылаться на столбец, содержащийся в уникальном ограничении, в этом случае:
CONSTRAINT [FK_ChildTableName_ChildColumnName_ParentTableName_ColumnInUniqueConstaintName]
Может быть, долго, да. Помогло ли это держать информацию в отчетах или я быстро перешел на то, что потенциальная проблема возникает во время prod-alert. 100% хотели бы знать мысли людей об этом соглашении об именах.
Ответ 8
В соответствии с ответами и комментариями здесь соглашение об именах, которое включает в себя таблицу FK, поле FK и таблицу PK (FK_FKTbl_FKCol_PKTbl), должно избегать конфликтов имен ограничений FK.
Итак, для данных таблиц здесь:
fk_task_userid_user
fk_note_userid_user
Итак, если вы добавили столбец для отслеживания последнего изменения задачи или примечания...
fk_task_modifiedby_user
fk_note_modifiedby_user
Ответ 9
Если вы не ссылаетесь на свой FK, который часто и с использованием MySQL (и InnoDB), вы можете просто позволить MySQL называть FK для вас.
В более позднее время вы можете найти нужное имя FK, выполнив запрос.