Що є правильним правилом іменування для MySQL FK?


Відповіді:


141

У MySQL немає необхідності надавати символічну назву обмеженням зовнішнього ключа. Якщо ім'я не вказано, InnoDB автоматично створює унікальне ім'я.

У будь-якому випадку, я використовую цю конвенцію:

fk_[referencing table name]_[referenced table name]_[referencing field name]

Приклад:

CREATE TABLE users(
    user_id    int,
    name       varchar(100)
);

CREATE TABLE messages(
    message_id int,
    user_id    int
);

ALTER TABLE messages ADD CONSTRAINT fk_messages_users_user_id 
    FOREIGN KEY (user_id) REFERENCES users(user_id);

Я намагаюся дотримуватися тих самих імен полів у таблицях посилань та посилань, як у user_idнаведеному вище прикладі. Коли це непрактично, я також додаю назву поля, на яку посилається, до назви зовнішнього ключа.

Ця угода про іменування дозволяє мені "вгадувати" символічну назву, просто переглядаючи визначення таблиць, а крім того, вона також гарантує унікальні імена.


13
Причиною створення символічного імені є посилання, коли ви хочете / потрібно скасувати обмеження. Oracle та SQL Server дозволяють вимкнути певні обмеження. Якщо у вас немає імені fk, ви повинні підтвердити, що обмеження є обмеженням зовнішнього ключа ...
OMG Ponies

11
Мені подобається використовувати подвійне підкреслення між назвою таблиці посилань та назвою таблиці, на яку посилаються. Це дає вам подвійні переваги алфавітних списків, утримуючи разом усі таблиці FK, і одночасно допомагаючи уникнути зіткнень і плутанини імен, коли є кілька імен таблиць слів. Я також опускаю польову частину імені, коли вона є тривіальною (тобто одне поле int посилається на ідентичність PK іншої таблиці).
Джоел Браун,

2
Що робити, якщо є більше 1 зовнішнього ключа? Приклад: member_id~> посилання на елемент таблиці, edited_id~> зовнішній ключ для відредагованого користувача, також посилання на член таблиці. Як я повинен назвати їх?
TomSawyer

@TomSawyer: Я додаю 'pk_' до всіх зовнішніх ключів, після чого йде таблиця, на яку посилаються (наприклад, 'members'), а потім використання / сенс (наприклад, 'editor' або 'author'). Отже, у мене є щось на зразок 'pk_members_author' або 'pk_members_editor'.
Nrgyzer

28

мій вибір інший. на мій погляд, таблиця повинна мати idполе, а не user_idодне, оскільки таблиця просто викликається user, отже:

CREATE TABLE users(
   id    int,
   name       varchar(100)
);

CREATE TABLE messages(
   id int,
   user_id    int
);

user_idв messagesтаблиці - поле fk, тому воно повинно чітко пояснити, який ідентифікатор ( user_id).

на мій погляд, цілком зрозумілою конвенцією іменування може бути:

fk_[referencing table name]_[referencing field name]_[referenced table name]_[referenced field name]

i.e.: `fk_messages_user_id_users_id`

Примітка:

  • у деяких випадках ви можете опустити другий елемент ([посилання на ім’я поля])
  • цей fk could є унікальним, оскільки, якщо messages_userіснує таблиця, ім'я поля посилання має бути user_id(і не просто id), а ім'я fk має бути:

    fk_messages_user_user_id_users_id

іншими словами, конвенція про іменування зовнішнього ключа гарантує вам впевненість в унікальних іменах, якщо ви також використовуєте конвенцію про іменування "поле посилання / посилання" (і, звичайно, ви можете вибрати власну).


4
Імена можуть зберігатися в коді. Зрештою, ви знайдете $idзмінну десь, не маючи уявлення, до якої таблиці вона належить. Чим старша ваша кодова база і чим більше людей над нею працювало, тим більшою ймовірністю це стає.
CJ Dennis

9

Якщо ви не знайдете посилання на fk, які часто після їх створення, один із варіантів - зробити це простим і дозволити MySQL зробити іменування за вас (як згадує Даніель Вассалло на початку своєї відповіді ).

Хоча ви не зможете однозначно "вгадати" імена обмежень за допомогою цього методу - ви можете легко знайти ім'я обмеження зовнішнього ключа, запустивши запит:

use information_schema;
select TABLE_NAME,COLUMN_NAME,CONSTRAINT_NAME, REFERENCED_TABLE_NAME,REFERENCED_COLUMN_NAME from KEY_COLUMN_USAGE where REFERENCED_TABLE_SCHEMA = 'your_db_schema_name' ORDER BY TABLE_NAME;

Наприклад, із запиту ви можете отримати таке:

+------------+-------------+-----------------+-----------------------+------------------------+
| TABLE_NAME | COLUMN_NAME | CONSTRAINT_NAME | REFERENCED_TABLE_NAME | REFERENCED_COLUMN_NAME |
+------------+-------------+-----------------+-----------------------+------------------------+
| note       | taskid      | note_ibfk_2     | task                  | id                     |
| note       | userid      | note_ibfk_1     | user                  | id                     |
| task       | userid      | task_ibfk_1     | user                  | id                     |
+------------+-------------+-----------------+-----------------------+------------------------+

Якщо цей додатковий крок для вас не надто великий, тоді ви зможете легко знайти шуканий вами fk.


1
fk-[referencing_table]-[referencing_field]

Причиною є поєднання referencing_tableта referencing_fieldунікальна база даних. Таким чином, ім’я зовнішнього ключа легко читається, наприклад:

table `user`:
    id
    name
    role

table `article`:
    id
    content
    created_user_id /* --> user.id */
    reviewed_user_id /* --> user.id */

Отже, у нас є два зовнішні ключі:

fk-article-created_user_id
fk-article-reviewed_user_id

Додавання userназви таблиці до імені іноземного ключа є зайвим.


Що робити, якщо ім’я бази даних user_role? userі roleмають багато томових відносин і user_roleє таблицею, яка містить весь зовнішній ключ. Це повинно бути fk_user_role_role?
Đức Tâm

@ NguyễnĐứcTâm fk-user_role-role
Văn Quyết
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.