Зачем указывать атрибуты первичного/внешнего ключа в именах столбцов

Question

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

select t1.col_a, t1.col_b, t2.col_z 
from t1 inner join t2 on t1.id_foo_pk = t2.id_foo_fk 

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

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

select t1.col_a, t1.col_b, t2.col_z 
from t1 inner join t2 on t1.id_foo = t2.id_foo 

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

tx inner join ty on tx.id_bar = ty.id_bar 

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

Какая проблема решается здесь? (Я знаю, что это приглашение для обсуждения и не стесняйтесь этого делать. Но в то же время я хочу найти ответ, в котором я действительно могу что-то пропустить).

Answer 1

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

SELECT * FROM foo JOIN bar USING (foo_id); 

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

SELECT * FROM foo JOIN bar ON (foo.foo_id = bar.foo_id); 

Заметим, однако, бывают случаи, когда вы не можете назвать внешний ключ так же, как первичный ключ он ссылается. Например, в таблице, имеющей самореференцию:

CREATE TABLE Employees (
    emp_id INT PRIMARY KEY, 
    manager_id INT REFERENCES Employees(emp_id) 
); 

Также таблица может иметь несколько внешних ключей к одной и той же родительской таблице. Полезно использовать имя столбца, чтобы описать природу отношений:

CREATE TABLE Bugs (
    ... 
    reported_by INT REFERENCES Accounts(account_id), 
    assigned_to INT REFERENCES Accounts(account_id), 
    ... 
); 

мне не нравится, чтобы включить имя таблицы в имени столбца. Я также избегаю обязательного «id» в качестве имени столбца первичного ключа в каждой таблице.

Answer 2

Я согласен с тобой. Внесение этой информации в название столбца привнесет из себя дерьмовую венгерскую нотацию в ранние дни Windows.

Answer 3

Я согласен с вами - я другой подход, который я видел рекомендуется во многих корпоративных средах:

Имя столбцов в формате TableNameFieldName, так что если у меня есть таблица клиентов и UserName был один из мои поля, поле будет называться CustomerUserName. Это означает, что если бы у меня была другая таблица под названием Invoice, а имя пользователя клиента было внешним ключом, я бы назвал это InvoiceCustomerUserName, и когда я назову его, я бы назвал его Invoice.CustomerUserName, которое сразу же сообщит мне, в какой таблице оно находится.

Кроме того, это присвоение имен позволяет отслеживать таблицы, из которых столбцы приходят, когда вы соединяетесь.

Я использую только FK_ и PK_ в именах ACTUAL внешних и первичных ключей в СУБД.

Answer 4

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

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

Имейте хороший!

Answer 5

Я использую только имя_таблицы с суффиксом идентификатора для первичного ключа, например. CustomerId и внешние ключи, ссылающиеся на другие таблицы, также называются CustomerId. Когда вы ссылаетесь в приложении, становится очевидной таблица из свойств объекта, например. Customer.TelephoneNumber, Customer.CustomerId и т. Д.

Answer 6

Я поддержал большинство идей, предложенных здесь в течение 20-летних лет, которые я разрабатывал с базами данных SQL, я смущен, чтобы сказать. Большинство из них доставляли мало или не ожидали каких-либо преимуществ и были с задним числом, боль в шее.

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

Кому это все объяснение? Кто-то, кто тратит всего несколько минут на дизайн, в любом случае не будет делать ничего серьезного. Тот, кто планирует работать с ним в течение долгого времени, узнает об этом, если вы назвали свои столбцы на санскрите.

Игнорирование составных первичных ключей, я не понимаю, почему для первичного ключа недостаточно «id» и «_id» для внешних ключей.

Таким образом, типичное условие соединения становится customer.id = order.customer_id.

Где существует более чем одна связь между двумя таблицами, я был бы склонен использовать ассоциацию вместо имени таблицы, так что, возможно, «parent_id» и «child_id», а не «parent_person_id» и т.д.