Схема именования внешнего ключа

Question

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

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

task (id, userid, title)
note (id, taskid, userid, note);
user (id, name)

Если у Задач есть Заметки, Задачи принадлежат Пользователям, а у Пользователей - Примечания.

Как бы назвали три внешних ключа в этой ситуации? Или же, это вообще имеет значение ?

Обновление : Этот вопрос касается имен внешних ключей, а не имен полей!

Answer 1

Стандартное соглашение в SQL Server:

FK_ForeignKeyTable_PrimaryKeyTable

Так, например, ключ между заметками и заданиями будет:

FK_note_task

И ключ между задачами и пользователями будет:

FK_task_user

Это дает вам «на первый взгляд» представление о том, какие таблицы участвуют в ключе, что позволяет легко увидеть, от каких таблиц зависит конкретная (названная первая) (названная вторая). В этом случае полный набор ключей будет:

FK_task_user
FK_note_task
FK_note_user

Таким образом, вы можете видеть, что задачи зависят от пользователей, а заметки зависят как от задач, так и от пользователей.

Answer 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))
        ...

Answer 3

Как насчет FK_TABLENAME_COLUMNNAME?

K eep I t S орудие S тупо, когда это возможно.

Answer 4

Обычно я просто оставляю свой PK с именем id, а затем объединяю свое имя таблицы и имя ключевого столбца при именовании FK в других таблицах. Я никогда не зацикливался на верблюжьем загоне, потому что некоторые базы данных отбрасывают чувствительность к регистру и в любом случае просто возвращают все заглавные или строчные буквы. В любом случае, вот как будет выглядеть моя версия ваших таблиц:

task (id, userid, title);
note (id, taskid, userid, note);
user (id, name);

Обратите внимание, что я также называю свои таблицы в единственном числе, потому что строка представляет один из объектов, которые я сохраняю. Многие из этих соглашений являются личными предпочтениями. Я бы предположил, что более важно выбрать конвенцию и всегда использовать ее, чем принять чужую конвенцию.

Answer 5

Примечание от Microsoft относительно SQL Server:

Ограничение FOREIGN KEY не обязательно должно быть связано только с ПЕРВИЧНЫМ КЛЮЧЕВОЕ ограничение в другой таблице; это также может быть определено для ссылки столбцы УНИКАЛЬНОГО ограничения в другой таблице.

поэтому я буду использовать термины, описывающие зависимость, вместо традиционных терминов первичные / внешние отношения.

При ссылке на ПЕРВИЧНЫЙ КЛЮЧ таблицы независимый (родительский) по столбцам с аналогичными именами в таблице зависимый (дочерний) я опускаю имя (и) столбца ):

FK_ChildTable_ParentTable

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

FK_ChildTable_childColumn_ParentTable_parentColumn

Answer 6

Это, вероятно, чрезмерное убийство, но оно работает для меня. Это очень помогает мне, особенно когда я имею дело с VLDB. Я использую следующее:

CONSTRAINT [FK_ChildTableName_ChildColName_ParentTableName_PrimaryKeyColName]

Конечно, если по какой-то причине вы не ссылаетесь на первичный ключ, вы должны ссылаться на столбец, содержащийся в уникальном ограничении, в данном случае:

CONSTRAINT [FK_ChildTableName_ChildColumnName_ParentTableName_ColumnInUniqueConstaintName]

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

Answer 7

Мой обычный подход

FK_ColumnNameOfForeignKey_TableNameOfReference_ColumnNameOfReference

Или другими словами

FK_ChildColumnName_ParentTableName_ParentColumnName

Таким образом, я могу назвать два внешних ключа, которые ссылаются на одну и ту же таблицу, как history_info table с column actionBy and actionTo из users_info таблицы

Это будет похоже на

FK_actionBy_usersInfo_name - For actionBy
FK_actionTo_usersInfo_name - For actionTo

Обратите внимание:

Я не включил имя дочерней таблицы, потому что это кажется мне здравым смыслом, я нахожусь в таблице ребенка, поэтому я легко могу принять имя таблицы ребенка. Его общий символ равен 26 и хорошо соответствует пределу оракула в 30 символов , о котором говорил Чарльз Бернс в комментарии здесь

Примечание для читателей: многие из лучших практик, перечисленных ниже, не работают в Oracle из-за ограничения имени в 30 символов. Имя таблицы или Имя столбца уже может быть близко к 30 символам, поэтому соглашение объединение двух в одно имя требует стандарта усечения или другие хитрости. - Чарльз Бернс

Answer 8

Попробуйте использовать UUID версии 4 в верхнем регистре с заменой первого октета на FK и '_' (подчеркивание) вместо '-' (тире).

* 1003 Е.Г. *

• FK_4VPO_K4S2_A6M1_RQLEYLT1VQYV
• FK_1786_45A6_A17C_F158C0FB343E
• FK_45A5_4CFA_84B0_E18906927B53

Обоснованием является следующее

• Строгий алгоритм генерации => унифицированные имена ;
• Длина ключа составляет менее 30 символов , что является ограничением длины именования в Oracle (до 12c);
• Если имя вашей сущности меняется, вам не нужно переименовывать свой FK , как в подходе, основанном на имени сущности (если БД поддерживает оператор переименования таблиц);
• Редко можно использовать имя ограничения внешнего ключа. Например. Инструмент БД обычно показывает, к чему применяется ограничение. Не нужно бояться загадочного взгляда, потому что вы можете избежать его использования для «расшифровки».

Answer 9

Если вы не часто ссылаетесь на свои FK и используете MySQL (и InnoDB), тогда вы можете просто позволить MySQL назвать FK для вас.

Позже вы можете найти нужное имя FK, выполнив запрос .

Answer 10

Основываясь на ответах и ​​комментариях здесь, соглашение об именах, которое включает в себя таблицу FK, поле FK и таблицу PK (FK_FKTbl_FKCol_PKTbl), должно избегать коллизий имени ограничения FK.

Итак, для приведенных таблиц здесь:

fk_task_userid_user
fk_note_userid_user

Итак, если вы добавите столбец, чтобы отслеживать, кто в последний раз изменил задачу или заметку ...

fk_task_modifiedby_user
fk_note_modifiedby_user