Id ou [TableName] Id comme clé primaire/identifiant d'entité

Question

Est-il préférable d'utiliser "Id" comme nom de colonne pour une clé primaire ou "[TableName] Id" comme convention de dénomination?

Tableau: Compte
clé primaire: Id

- contre -

Tableau: Compte
clé primaire: accountid

Il semble être divisé environ 50%/50% dans les implémentations que j'ai vu . Quels sont les avantages et les inconvénients de chaque approche?

Suivi:

Est-il judicieux d'utiliser une convention dans ma base de données, et une autre sur mes entités dans le code? Ou devrais-je les garder cohérents? Comment cela fonctionnerait-il le mieux dans la plupart des ORM?

Answer 1

TableNameID pour plus de clarté

1. Améliorer REJOIGNEZ lisibilité
2. clarté, par exemple, lorsque plusieurs FK colonnes "ID" (correspond à PK FK)
3. ID est un mot-clé réservé

Answer 2

La première méthode est la convention de nommage OOP la plus probable.

La seconde méthode présente l'avantage d'éviter les noms de colonne ambigus dans les requêtes de jointure. Bien que vous puissiez utiliser un alias, parfois cela n'est pas possible, comme dans certains frameworks ORM (EntitySpaces vient à l'esprit).

Answer 3

I utiliser l'identifiant Comment définiriez-vous une table utilisateur avec un identifiant de compte en tant que clé étrangère? Nommez-vous cette colonne AccountAccountID ou AccountID?

Mais la partie la plus importante est d'être cohérent à mon avis, de quelque manière que vous choisissiez.

Modifier: Je pense qu'en lisant mon commentaire, la logique de mon argument est désactivée, car il est évident que vous n'appelez jamais de champ AccountAccountID. Mais à première vue en utilisant [TableName] ID en tant que clé primaire et [TableName] ID en tant que clé étrangère ainsi se sent étrange pour moi. Il semble que vous utilisiez deux règles différentes pour deux choses qui devraient suivre le même ensemble de normes. Aussi je pense que Account.ID et User.AccountID est plus lisible et sémantiquement correct.

Answer 4

Je suis d'accord avec vous. C'est une scission. Id par lui-même n'est pas très descriptif cependant. Normalement, je n'utilise pas Id, car il est beaucoup plus sûr d'utiliser AccountId lorsqu'il est question de risque d'injection SQL.

Answer 5

J'ai trouvé que le nommage explicite (TableId) est meilleur. Pour commencer, toutes les clés étrangères ont un nom naturel de cette façon (ID [RelatedTable]). Et puis, je finis toujours par renvoyer des requêtes jointes avec deux types d'ID, où je serais obligé de les alias correctement afin que le client puisse distinguer AccountId et ClientId. L'utilisation de noms de clés explicites simplifie également la logique de ma couche d'accès aux données/orm car elle n'a pas à gérer l'ambiguïté, par exemple.La clé de type de compte est toujours 'AccountId', pas 'Id' dans certaines requêtes et 'AccountId' dans les autres. Mon 2c.

Answer 6

Eh bien, j'utilise un schéma tout le temps et le trouve très utile.

La clé primaire dans une table est toujours appelée "ID", avec des clés de séparation j'appelle la colonne avec l'information d'identification de ligne "ID" sinon aucune colonne "ID" n'est appelée.

Toutes les clés étrangères utilisent le nom de la table référencée.

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

Évitez les mots courants tels que ID, état, description en tant que noms de colonnes.

noms d'utilisation comme WarehouseID, WarehouseStatus, WarehouseDescription, ceux-ci feront de votre vie plus facile lorsque vous écrivez vos requêtes, le code de recherche, lire l'ancien code, etc.