Схема іменування іноземних ключів

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

Враховуючи ці таблиці:

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_TABLENAME_COLUMNNAME?

До EEP I т S реалі S tupid щоразу , коли це можливо.

Нотатка від Microsoft про SQL Server:

Обмеження ЗАМОВНЕГО КЛЮЧА не повинно бути пов'язане лише з ПЕРВИЧНИМ КЛЮЧНИМ обмеженням в іншій таблиці; його також можна визначити для посилання на стовпці обмеження UNIQUE в іншій таблиці.

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

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

FK_ChildTable_ParentTable

Посилаючись на інші стовпці, або назви стовпців змінюються між двома таблицями, або просто для явного:

FK_ChildTable_childColumn_ParentTable_parentColumn

Зазвичай я просто залишаю свій ПК з іменем id, а потім з'єдную своє ім'я таблиці та ім'я стовпця ключів під час іменування FK в інших таблицях. Я ніколи не турбуюся з обробкою верблюда, тому що деякі бази даних відкидають чутливість до регістру і просто в будь-якому випадку повертають усі верхні та малі регістри. У будь-якому випадку, ось як виглядатиме моя версія ваших таблиць:

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

Зауважте, що я також називаю свої таблиці в однині, тому що рядок являє собою один із об'єктів, які я зберігаю. Багато з цих конвенцій є особистими уподобаннями. Я б припустив, що важливіше обирати конвенцію і завжди використовувати її, ніж приймати чужу конвенцію.

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

CONSTRAINT [FK_ChildTableName_ChildColName_ParentTableName_PrimaryKeyColName]

Звичайно, якщо з якихось причин ви не посилаєтесь на первинний ключ, ви повинні посилатися на стовпець, що міститься в унікальному обмеженні, в цьому випадку:

CONSTRAINT [FK_ChildTableName_ChildColumnName_ParentTableName_ColumnInUniqueConstaintName]

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

Мій звичайний підхід такий

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 символів, тому умова, що поєднує два в одне ім'я, вимагає стандартних скорочень або інших хитрощів. - Чарльз Бернс

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

Отже, для наведених таблиць тут:

fk_task_userid_user
fk_note_userid_user

Отже, якщо ви додаєте стовпець, щоб відстежувати, хто востаннє змінив завдання чи примітку ...

fk_task_modifiedby_user
fk_note_modifiedby_user

Якщо ви не часто посилаєтесь на свої FK-файли та використовуєте MySQL (та InnoDB), ви можете просто дозволити MySQL назвати FK для вас.

Пізніше ви можете знайти потрібне ім'я FK, запустивши запит .

Спробуйте використовувати верхній регістр UUID версії 4 з першим октетом, заміненим на FK та "_" (підкреслення) замість "-" (тире).

Напр

• FK_4VPO_K4S2_A6M1_RQLEYLT1VQYV
• FK_1786_45A6_A17C_F158C0FB343E
• FK_45A5_4CFA_84B0_E18906927B53

Обґрунтування наступне

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