Id или [TableName] Id в качестве первичного ключа / идентификатора объекта

Question

Желательно ли использовать "Id" в качестве имени столбца для первичного ключа или "[TableName] Id" в качестве соглашения об именах?

Таблица: Счет
Первичный ключ: Id

- против -

Таблица: Счет
Первичный ключ: AccountId

Кажется, он разделен примерно на 50% / 50% в реализациях, которые я видел. Каковы преимущества и недостатки каждого подхода?

Последующий:

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

Answer 1

TableNameID для наглядности

1. Улучшение читабельности JOIN
2. Ясность, скажем, когда несколько столбцов "ID" FK (PK соответствует FK)
3. ID является зарезервированным ключевым словом

Answer 2

Я использую ID. Как бы вы настроили таблицу пользователей с идентификатором учетной записи в качестве внешнего ключа? Вы бы назвали этот столбец AccountAccountID или AccountID?

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

Редактировать : Я думаю, что при чтении моего комментария логика моего аргумента отключена, поскольку очевидно, что вы никогда не вызовете поле AccountAccountID. Но на первый взгляд использование идентификатора [TableName] в качестве первичного ключа и идентификатора [TableName] в качестве внешнего ключа также кажется странным для меня. Кажется, вы используете два разных правила для двух вещей, которые должны следовать одному и тому же набору стандартов. Также я считаю, что Account.ID и User.AccountID более читабельны и семантически правильны.

Answer 3

Избегайте распространенных слов, таких как идентификатор, статус, описание в качестве имен столбцов.

используйте имена, такие как WarehouseID, WarehouseStatus, WarehouseDescription, они облегчат вашу жизнь, когда вы будете писать запросы, искать код, читать старый код и т. Д.

Answer 4

Я обнаружил, что явное именование (TableId) лучше. Для запуска все внешние ключи имеют естественное имя таким образом ([RelatedTable] Id). А также я всегда заканчиваю тем, что возвращаю объединенные запросы с двумя типами идентификаторов в любом случае, где я вынужден правильно их псевдонимы, чтобы клиент мог различать AccountId и ClientId. Использование явных имен ключей также упрощает мою логику доступа к данным / уровня orm, так как это не должно иметь дело с неоднозначностью, например. ключом типа учетной записи всегда является «AccountId», а не «Id» в некоторых запросах и «AccountId» в других. Мой 2с.

Answer 5

Первый метод - более вероятное соглашение об именах ООП.

Преимущество второго метода состоит в том, что он позволяет избежать неоднозначных имен столбцов в запросах на соединение. Хотя вы можете использовать псевдоним, иногда это невозможно, как в некоторых средах ORM (EntitySpaces приходит на ум).

Answer 6

Ну, я все время использую одну схему и считаю ее очень полезной.

Первичный ключ в таблице всегда называется «ID», с разделенными ключами я называю столбец с информацией об идентификации строки «ID», в противном случае столбец «ID» не вызывается.

Все внешние ключи используют имя таблицы, на которую они ссылаются.

CREATE TABLE `Person`  
(
  `ID` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  `FirstName` VARCHAR(255)  NOT NULL,
  `LastName` VARCHAR(255)  NOT NULL,
  PRIMARY KEY (`ID`)
);

CREATE TABLE `Tutorial`
(
  `ID` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
  `Name` VARCHAR(255) NOT NULL,
  PRIMARY KEY (`ID`)
);

CREATE TABLE `Class`
(
  `Person` INTEGER UNSIGNED NOT NULL,
  `Tutorial` INTEGER UNSIGNED NOT NULL
  PRIMARY KEY (`Person`, `Tutorial`)
);

Answer 7

Я согласен с вами. Это раскол. Идентификатор сам по себе не очень описательный, хотя. Обычно я не использую Id, потому что это намного безопаснее использовать AccountId при возможном риске внедрения SQL.