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

Как насчет FK_TABLENAME_COLUMNNAME?

Keep яt Simple Stupid, когда это возможно.

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

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

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

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

FK_ForeignKeyTable_PrimaryKeyTable

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

FK_note_task

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

FK_task_user

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

FK_task_user
FK_note_task
FK_note_user

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

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

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

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

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

fk_task_userid_user
fk_note_userid_user

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

fk_task_modifiedby_user
fk_note_modifiedby_user

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

A FOREIGN KEY constraint does not have to be linked only to a PRIMARY KEY constraint in another table; it can also be defined to reference the columns of a UNIQUE constraint in another table.

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

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

FK_ChildTable_ParentTable

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

FK_ChildTable_childColumn_ParentTable_parentColumn

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

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

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

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 символов., о чем заявил Чарльз Бернс в комментарии здесь

Note for readers: Many of the best practices listed below do not work in Oracle because of its 30 character name limit. A table name or column name may already be close to 30 characters, so a convention combining the two into a single name requires a truncation standard or other tricks. – Charles Burns

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

CONSTRAINT [FK_ChildTableName_ChildColName_ParentTableName_PrimaryKeyColName]

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

CONSTRAINT [FK_ChildTableName_ChildColumnName_ParentTableName_ColumnInUniqueConstaintName]

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

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

Например.

• FK_4VPO_K4S2_A6M1_RQLEYLT1VQYV
• FK_1786_45A6_A17C_F158C0FB343E
• FK_45A5_4CFA_84B0_E18906927B53

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

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