Схема именования иностранных ключей

Я только начинаю работать с внешними ключами в первый раз, и мне интересно, есть ли у них стандартная схема именования?

Учитывая эти таблицы:

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, выполнив запрос.