Pourquoi le préfixe des noms de colonne est-il considéré comme une mauvaise pratique?

Selon une publication SO populaire, il est considéré comme une mauvaise pratique de préfixer les noms de table. Dans mon entreprise, chaque colonne est préfixée par un nom de table. C'est difficile à lire pour moi. Je ne suis pas sûr de la raison, mais cette dénomination est en fait la norme de l'entreprise. Je ne supporte pas la convention de dénomination, mais je n'ai aucune documentation pour sauvegarder mon raisonnement.

Tout ce que je sais, c'est que lire AdventureWorks est beaucoup plus simple. Dans cette base de données de notre entreprise, vous verrez un tableau, Personne et il pourrait avoir un nom de colonne:

Person_First_Name
ou peut-être même
Person_Person_First_Name (ne me demandez pas pourquoi vous voyez la personne 2x)

Pourquoi est-il considéré comme une mauvaise pratique de préfixer les noms de colonne? Les soulignés sont-ils également considérés comme mauvais en SQL?

Les caractères de soulignement ne sont pas maléfiques mais plus difficiles à saisir. Ce qui est mauvais, c'est de changer les normes en cours de route sans réparer tous les objets existants. Vous avez maintenant personId, Person_id, etc. et vous ne vous souvenez plus quelle table utilise les traits de soulignement ou non. La cohérence des noms (même si vous n'aimez pas personnellement les noms) facilite le codage.

Personnellement, le seul endroit où je ressens le besoin d'utiliser le nom de la table dans une colonne est sur la colonne ID (l'utilisation de simplement ID est un contre-modèle dans la conception de la base de données comme toute personne qui a fait de nombreuses requêtes de création de rapports peut vous le dire. C'est tellement amusant de renommer 12 colonnes dans votre requête à chaque fois que vous rédigez un rapport.) Cela facilite également la connaissance immédiate des FK dans d'autres tables car ils portent le même nom.

Cependant, dans une base de données mature, c'est plus de travail qu'il ne vaut la peine de changer une norme existante. Acceptez simplement que c'est la norme et continuez, il y a des choses beaucoup plus critiques qui doivent être corrigées en premier.

Un argument pour le préfixe du nom de colonne empêcherait les «collisions» de noms lors de la jonction de plusieurs tables ET lorsque le créateur de la requête n'utilise pas d'alias.

SELECT person.name, company.name FROM person JOIN company ON ...

SELECT * FROM person JOIN company ON ...

Les deux requêtes auraient deux colonnes "nom" ( nom_1, nom_2 ) sans "dire" à quelle entité elle appartient. Et vous ne pouvez jamais être sûr des noms de colonne générés (sera-ce nom_2 ou nom_3 ou ...). Si vous utilisez le préfixe de nom de table, les noms de colonne seraient nom_personne , nom_entreprise afin que vous connaissiez chaque nom auquel l'entité appartient, et vous savez que les noms de colonne resteront constants (si vous les obtenez en Java en utilisant JDBC par exemple ).

Les deux arguments peuvent être ignorés si vous utilisez l'aliasing, mais je pense que la plupart des conventions de codage appliquées dans les entreprises découlent du fait que de nombreux programmeurs (juniors) ne suivent pas les bonnes pratiques. Dans ce cas, par exemple, l'utilisation du caractère générique sur une instruction SELECT peut provoquer des problèmes sans le préfixe de nom.

Quant au trait de soulignement dans les noms de table et de colonne, je l'utilise beaucoup car j'utilise uniquement des minuscules dans les noms plus le trait de soulignement comme séparateur. Utiliser uniquement des minuscules permet de distinguer les identifiants des mots clés SQL (que je tape en majuscules):

SELECT person_name, COUNT(bought_product) FROM bought_products WHERE person_name LIKE 'A%'

L'ajout de ce type de préfixes aux noms de colonnes rendra une table plus difficile à faire évoluer. Par exemple: si vous réalisez finalement que vous voulez / devez changer le nom de la table, vous devrez modifier la structure complète de votre table (c'est-à-dire non seulement le nom de la table, mais le nom de toutes ses colonnes). Cela rendrait également plus difficile la mise à jour des index de la table et du code des clients qui l'interrogent.

Il y a des exceptions si elles sont utilisées judicieusement (selon la réponse de Patrick Karcher sur votre lien) pour les noms de colonnes communs (normalement seulement ID, parfois Name) qui seraient trop souvent ambigus .

Une autre meilleure pratique consiste à toujours qualifier les colonnes et les objets dans vos requêtes. Les préfixes de colonne deviennent donc inutiles et encombrent votre code.

Comparez-les: lequel est le plus facile à regarder?

SELECT P.name, P.Salary FROM dbo.Person P

SELECT Person.Name, Person.Salary FROM dbo.Person Person

SELECT dbo.Person.name, dbo.Person.Salary FROM dbo.Person

SELECT Person.Person_name, Person.Person_Salary FROM dbo.Person Person

En général, il ne semble vraiment pas y avoir de normes omniprésentes. La question à laquelle vous avez lié a plusieurs réponses très appréciées avec des conventions totalement différentes. Bien sûr, tout le monde va défendre ses propres normes, et il est beaucoup plus important de conserver des conventions cohérentes dans un projet.

Cela dit, le préfixe des noms de colonne semble exagéré. Vous savez déjà avec quelle table vous travaillez, et une situation avec deux colonnes de tables différentes portant le même nom peut être facilement résolue en utilisant des alias de table ou de colonne.

Dans TSQL, vous pouvez faire référence aux champs sous la forme TableName.FieldName si vous voulez éviter toute ambiguïté. L'ajout de noms de table aux noms de champ enlève en fait la lisibilité, ce qui en fait TableName.TableName_FieldName ou similaire. Je pense que l'utilisation de soulignements ou non est plus un choix personnel. Je préfère CamelCase et j'utilise _ lorsque je veux ajouter un suffixe ou similaire, par exemple TableName_Temp, mais c'est juste moi.

Une fois, j'ai travaillé sur un système où nous avons décidé d'utiliser des codes courts pour préfixer les colonnes. Les champs PK ont utilisé le "nom de table complet" comme préfixe, et toutes les autres colonnes ont utilisé 2-4 caractères de manière cohérente comme préfixe. Chaque colonne a également utilisé un domaine de données comme suffixe. Si cela est fait de manière cohérente, il peut être très agréable et propre. Il est absurde qu'une norme de dénomination d'un type ou d'un autre implique un codage bâclé. La présence d'une norme cohérente est ce qui est important. J'ai vu un certain nombre de bases de données qui sont incohérentes parce qu'il n'y a pas de norme claire, et que plus que toute autre chose m'indiquerait qu'il pourrait y avoir des problèmes dans les structures de données. Si le concepteur d'une base de données ne peut même pas nommer de manière cohérente des objets et leurs enfants,

Le préfixe est une mauvaise pratique car il provoque le problème qu'il est censé éviter. Comme vous l'avez dit, il est très difficile de lire les colonnes préfixées. Si vous vous retrouvez avec des noms de colonne dupliqués dans une requête où vous joignez deux tables, vous pouvez le résoudre, ou c'est une vue, une procédure stockée ou une fonction tabulaire définie par l'utilisateur qui le fait pour vous si vous vous retrouvez constamment à rejoindre des tables particulières.

En ce qui concerne l'utilisation soulignée dans un nom de table, c'est un argument religieux. Au final, cela augmente la visibilité et facilite les choses. Je n'aurais généralement jamais d'espaces ou de tables dans un nom de colonne ou de table. Cependant, je peux faire une exception pour les tables ou les vues qui n'étaient utilisées que par un package de rapports ou exportées vers un fichier CSV.

De nombreuses bases de données ont des limites strictes sur le nombre de caractères dans un nom de colonne (par exemple Oracle).

Si vous travaillez avec une base de données qui autorise les noms de colonne longs, mais que vous décidez ultérieurement de migrer cette structure vers un autre système de base de données, les préfixes augmenteront les chances que vos noms de colonne ne soient pas valides.

Bien que vous travailliez actuellement avec SQL Server, personne ne peut prédire l'avenir, et il est possible que votre logiciel doive fonctionner sur plusieurs bases de données à l'avenir.

Envisagez d'écrire un dictionnaire de données (ou "registre"). J'entends par là un document contenant tous les éléments de données de votre modèle: nom, description, etc. Il doit être indépendant de la mise en œuvre du modèle, par exemple ne doit pas mentionner les noms de table. Comment désambiguïseriez-vous des noms tels que «ID», «Type» et «Code»?

Une approche consiste à suivre les directives de la norme internationale ISO / CEI 11179 - après tout, pourquoi réinventer la roue? La structure de base est:

[Object] [Qualifier] Property RepresentationTerm

avec des délimiteurs entre les éléments: SQL ne joue pas bien avec les espaces dans les noms de colonnes et le soulignement fonctionne bien visuellement.

J'ai le sentiment que quelqu'un de votre organisation essayait de suivre ces lignes directrices lorsqu'il a proposé des noms d'éléments tels que Person_Person_First_Name.

L'exemple que j'aime montrer est le dictionnaire de données du UK Nation Health Service (NHS) .

Je ne pense donc pas que la convention de dénomination que vous devez utiliser avec les sons soit trop mauvaise.

Lors de l'implémentation, par exemple en SQL, certaines personnes aiment omettre les sous-éléments Object, Qualifier et Property lorsque le nom de la table fournit un contexte, par exemple, person_first_namedevient first_namedans la Persontable, etc. en raison de son emplacement dans le modèle physique semble bon. Quiconque pense que ce n'est pas une bonne idée de suivre cette règle devrait être chargé de documenter toutes les variantes de nom qu'il a utilisées :)

Vous trouverez un bon résumé de l'ISO 11179 dans le livre Joe Celko's Programming Style , y compris des preuves pour préférer les traits de soulignement comme délimiteurs dans les noms de colonne.

Certains trouvent plus facile dans le code de savoir de quelle table proviennent les données, cependant, si vous parlez d'un système orienté objet, vous devez utiliser le contexte du nom pour savoir d'où il vient, dans ce cas le nom de la table.

Personnellement, le préfixe du nom de table indique que les développeurs ne sont pas très qualifiés et que vous approfondissez, vous trouverez de nombreuses autres conventions de codage incorrectes et si je devais deviner que l'application a trop de tables, est boguée, etc.