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

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

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

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

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

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

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

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

Всего хорошего!

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

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

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» в качестве имени столбца первичного ключа в каждой таблице.

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

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

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

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

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

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