Discussion :

[SQLpro]

Prenons un exemple simple qui a couté très cher.... Les civilités : Mr. Mme. Mlle..
le législateur à récemment interdit les Mlle sous prétexte de sexisme.
Si votre clé étrangères est littéral avec "Mlle." comme code il a fallu mettre à jour toutes les lignes de la table contenant ce libellé. Comme ces lignes sont nombreuses, la table a due être verrouillé en mode exclusif le temps de procéder à cet UPDATE.
Si maintenant votre clé est un entier, aucune modification de clé n'est à faire dans les tables fille. Il suffit dans la table mère de remplacer le libellé par Madame... Ok, nous aurons deux libellé avec Madame dans la base... Et alors ? Ou est le problème ? On a même la traçabilité du fait qu'avant ces personnes étaient des demoiselles. Il faudra simplement interdire, dans la liste déroulante le choix de la 2e Madame devenu obsolète, par exemple en utilisant une colonne "date d'obsolescence"....

A +

[fsmrel]

Bonjour,

Un petit mot en passant.

par exemple pour créer une commande en import il faut chercher l'id du client, l'id de la devise, l'id du magasin"

Si vos interlocuteurs insistent, pour utiliser des codes significatifs pour les clés primaires, tels que le code client, le code devise et le code magasin, ces codes doivent être strictement contrôlés par l'entreprise et pas par des organismes externes (cas par exemple du code devise). Ils doivent être invariants et non manipulables par des fonctions du genre SUBSTRING.

Ach ! L’époque heureuse où j’ai participé chez les opérateurs au passage à la numérotation à 8 chiffres puis à 10 chiffres des téléphones... Des montagnes de tables à faire évoluer...

Au plan des perfs, la hauteur des arbres (index) ne doit pas être supérieure à celle utilisée pour des codes de type INT, voire SMALLINT (codes des magasins).

Voir l’utilisation de l’identification relative (en relation avec le clustering des index et la réduction possiblement juteuse du nombre de jointures).

Quant à l’intégrité référentielle : combien de fois ai-je dû intervenir pour rattraper le coup chez nos clients (en moyenne 30% d’anomalies et un an de travail pour l’utilisateur à remettre les choses d’équerre).

Quand le pense que dans les années quatre-vingts, Yves Tabourier avait déjà tout dit sur les méfaits des codes significatifs...
Décidemment, nihil novi sub sole...

Courage, tatayo

[Paprick]

Bonjour,

Voici ma petite contribution à cette discussion !
Ma position est légèrement plus modérée quand à l'utilisation systématique d'identifiants non significatifs , même si mon raisonnement conduit bien souvent au même résultat .

En préambule, je rappelle que les dates, hautement significatives, contribuent bien souvent à la composition d'identifiants.
En fait, la problématique se situe à 2 niveaux : la performance et la maintenance.
Pour la performance, je ne reviendrai pas sur tout ce qui a été dit dans cette discussion, l'entier (sous toutes ses formes) sera toujours préférable.
Pour la maintenance, l'ennemi est le changement de structure de la clé qui peut provoquer des modifications en chaîne considérables sur les grosses bases de données.

L'utilisation systématique d'identifiants non significatifs de type compteur règle effectivement ces problèmes... ça n'en fait pas pour autant la seule approche acceptable (n'en déplaise à Tabourier).
Soyons pragmatiques : quels sont les qualités nécessaires pour un identifiant ?

• Unicité : bien évidemment, mais trop souvent considérée comme la seule.
• Formalisme : l'identifiant ne doit laissé aucun doute quant à la façon de l'écrire : numéro, code, réf, ... ce qui, pour moi, exclut de facto les textes "libres" et donc l'utilisation du VARCHAR.
• Légalité : l'exemple classique est bien sûr l'utilisation interdite du numéro de sécurité sociale.
• Irréductibilité : le sacro-saint principe de la clé minimale (attention aux surclés !).
• Pérennité : dans mes cours, je le traite en 3ème position, mais là je l'ai gardé pour la fin ! En effet, c'est au cœur de nos discussions : pourquoi favorise-t-on un identifiant non significatif ? Parce que, dépourvu de signification, il est forcément pérenne ! On pourrait donc s'arrêter là... Mais, la pérennité peut également exister avec des rubriques significatives : certes, il faut y regarder à 10 fois pour s'en assurer, mais partir du principe que cela ne peut exister me parait exagéré. Lorsque je définis, par exemple, le format d'un numéro de facture, qui par définition (comptable), n'a pas le droit d'évoluer dans le temps, pourquoi créer en plus un Id_Facture qui n'a rien à voir avec le système d'information alors que celui-ci nous en propose un. Et quand bien même, une fois tous les 10 ans, il faudrait mouliner la base pendant 48 heures pour réactualiser les structures, est-ce que le rapport intérêt/coût ne mérite pas d'être étudié ? Après, chacun fait ses choix, et l'usage systématique d'identifiants non significatifs en est un... mais pas forcément le seul, et en tout cas, ce n'est pas, à mon avis, une règle d'or intransgressible.

En résumé, l'important, c'est la pérennité, par forcément la non-significativité, même si bien souvent, l'un ne va pas sans l'autre.

Bonne continuation !

[Waldar]

Attention aussi aux rachats de société, qui peuvent aussi être un bon candidat à multiplier des codes factures. Certes, les ID aussi mais c'est plus simple à mettre à jour.

[Paprick]

Bonjour,

Attention aussi aux rachats de société, qui peuvent aussi être un bon candidat à multiplier des codes factures. Certes, les ID aussi mais c'est plus simple à mettre à jour.

Là, on tombe dans une situation particulièrement lourde à gérer quelle que soit la nature des identifiants, l'unicité étant systématiquement mise en danger dans le cas d'identifiants non significatifs.
Dans un tel cas, revisiter le modèle conceptuel de données dans son ensemble (au moins celui de la société rachetée) est toujours préférable, car il n'y aura pas que les codes factures à harmoniser.

[escartefigue]

Effectivement : lors de la fusion de plusieurs sociétés, il y a un processus de convergence des systèmes d'information, processus dans lequel il y a une étape incontournable consistant à renuméroter les doublons techniques tout en conservant la traçabilité (correspondance entre l'ancien et le nouvel identifiant).

[Luc Orient]

Bonjour,

Voici ma petite contribution à cette discussion !
Ma position est légèrement plus modérée quand à l'utilisation systématique d'identifiants non significatifs , même si mon raisonnement conduit bien souvent au même résultat .

Ah enfin un peu de fraîcheur et de nuance dans ce débat qui tourne parfois à la querelle digne des " islamos gauchistes " ou des ayatollahs de l'identifiant non significatif ...

L'argument le plus débile, avancé par l'ayatollah en chef, il se reconnaîtra sans doute, c'est que le choix d'un identifiant doit dépendre de la vitesse avec lequel le processeur traite les valeurs numériques entières ... ça c'est de l'argumentation de niveau conceptuel ou je ne m'y connais pas ...

[escartefigue]

L'argument le plus débile, avancé par l'ayatollah en chef, il se reconnaîtra sans doute, c'est que le choix d'un identifiant doit dépendre de la vitesse avec lequel le processeur traite les valeurs numériques entières ... ça c'est de l'argumentation de niveau conceptuel ou je ne m'y connais pas ...

Cet argument est tout à fait pertinent, mais toutes choses égales par ailleurs.
On ne choisit pas un intéger uniquement parce que le processeur sera plus efficace, mais parce que outre le fait d'avoir les qualités requises pour un identifiant primaire - stabilité, unicité et irréductibilité - il sera plus performant que tout autre type d'attribut.

On dit souvent que le MCD ne se préoccupe pas du "comment" mais uniquement du "quoi" et c'est vrai sur l'essentiel, c'est même une règle de modélisation, sauf que sur ce point particulier, il convient d'être vigilant

[Paprick]

Bonjour,

Je trouve cette discussion particulièrement intéressante : en effet, la vision d'un pur DBA diffère forcément d'un pur concepteur.
Et il est vrai que la problématique de la nature des identifiants est un débat qui oppose souvent les 2 "clans".
Il faut bien reconnaître que c'est un souci technique dont on n'est pas obligé de se préoccuper au niveau conceptuel ; d'ailleurs, dans mes cours (et dans mon propre livre), je propose la réalisation de MCD sans parler d'identifiant, et ça se passe très bien... Les identifiants apparaissent ensuite (à partir de la page 135 ! ) pour justement régler les problèmes techniques qui apparaitront au moment de générer le modèle logique (MLD).
D'ailleurs, je les appelle alors des MCDi (Modèle Conceptuel de Données informatisé).
Ensuite, les dernières tendances vont dans le sens de MCD qui prévoient tout pour une génération au plus près de ce que sera la structure de la BD... Et je plaide coupable avec Looping qui fait tout pour que le MCD permette d'avoir un reflet fidèle de la structure de données correspondante.