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

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

Я согласен с вами. Помещение этой информации в название колонки попахивает дерьмовым венгерским идиотизмом обозначений первых дней Windows.

Answer 2

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

SELECT * FROM foo JOIN bar USING (foo_id);

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

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 3

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

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

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

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

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

Если существует более одной ассоциации между двумя таблицами, я склонен использовать ассоциацию, а не имя таблицы, поэтому, возможно, "parent_id" и "child_id", а не "parent_person_id" и т. Д.

Answer 4

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

Answer 5

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

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

Хорошего вам!

Answer 6

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

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

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

Я использую только FK_ и PK_ в АКТУАЛЬНЫХ именах внешнего и первичного ключей в СУБД.