Discussion :

[philoutte]

Bonjour tout le monde.

On m’a demandé de réécrire un logiciel sur base d’un vieux truc qui a été développé en Access et je me pose une question de conception pour la DB car j’ai moins d’expérience dans ce domaine.

Dans le vieux logiciel, une commande porte un numéro L + 1 lettre selon le type de commande + 5 chiffres. Cela donne un numéro de commande unique.
De même un client est identifié par un numéro unique qui commence par 7 et qui est suivi de 6 chiffres.

Pour moi, ces informations peuvent servir d’ID et devenir une PK.

Néanmoins l’ancien concepteur a créé dans chacune des tables une colonne d’ID auto incrémenté et en a fait la PK et il fait ses relations sur base de cet ID.
De mon point de vue, ce qu'il fait est inutile vu que les 2 autres informations existent mais j’en ai parlé avec un ami et il n’est pas d’accord avec moi. Pour lui, je le cite : « ne jamais utiliser un ID externe a la db pour identifier un reccord, de plus pour mettre tes indexs c'est mieux sur des id gérés par la DB, j'aurais fait pareil sans hésiter ».

Donc voilà, j’aurais souhaité avoir l’avis d’autres personnes sur le sujet.

Une chose que je vois quand même qui pourrait justifier le fait de créer l’ID en plus. Ça serait pour optimiser la taille de la base. En effet, au vu de ce que j’ai comme identifiant de colonne, j’aurais :

• une colonne char(7) pour les commandes stockée sur 7 bytes si je ne me trompe pas
• une colonne int pour les clients stockée sur 4 bytes si je ne me trompe pas

Alors qu’avec un id auto incrémenté, je pourrais stocker ça dans des small int, stockés sur 2 bytes.
Ça permettrait de gagner un peu de place mais je pense que l’on est pas en train de parler de gagner des Go mais plutôt quelques Mo au vu de la masse de données (4000 commandes et 2500 clients en 20 ans).

Merci pour vos avis 😊

Philippe

[AaâÂäÄàAaâÂäÄàAaâÂäÄ]

Avec un id auto-incrémenté sur un entier, c'est aussi la taille des indexes qui est affecté positivement et les donc les performances des requêtes aussi.
Autre point, s'il y a une erreur dans le numéro de client ou de facture et que c'est la PK, bonne chance pour corriger ça !
C'est toujours une bonne idée d'utiliser une id non reliée à la business.

[philoutte]

Merci pour ta réponse :-)
Je vais donc garder cette idée d'id auto incrémenté.

[escartefigue]

Bonjour,

Il y a de nombreux arguments en faveur d'un identifiant technique attribué par le SGBD :

• les identifiants uniques candidats composés de combinaisons de lettres et de chiffres (L + 1 lettre selon le type de commande + 5 chiffres...) sont plus encombrants qu'une colonne de type integer à nombre de combinaisons égales.
  Sans compter qu'embarquer une constante "L" dans une PK c'est cramer un octet inutilement. Ca semble peu de choses, mais ça peut faire la différence quand on sait que les PK se propagent dans la plupart des index.
• plus encore, ces identifiants candidats utilisent des lettres ayant un sens fonctionnel (type de commande...). Ce faisant, si le rôle fonctionnel change (par exemple le type de commande, le type de client...), alors la valeur change. Ce qui pour une PK est catastrophique, car la valeur d'une PK se propage via l'intégrité dans toutes les FK. Une mise à jour de PK peut provoquer un très grand nombre de mises à jour, voire mettre par terre la BDD !
• les caractères, qu'ils soient fixes ou variables, sont sensibles à la collation. Ce faisant, la même valeur dans deux colonnes de collations différentes auront des comportements différents.

Une PK doit être "not null" et unique, mais une bonne PK doit aussi être stable et concise, les colonnes sémantiques sont très rarement stables et rarement concises.
C'est pourquoi on leur préfère le plus souvent une colonne technique, de type integer car plus performant que le char et plus concis.

Note : parler d'auto incrément est réducteur, de nombreux SGBD proposent la possibilité d'incrémenter ou de décrémenter au choix du DBA.

[philoutte]

Merci pour ton complément d'information