Au niveau base de données, c'est déjà beaucoup plus propre que (par exemple)
:
- des clefs primaires nommés n'importe comment (name, codpers, numbase,
etc.)
- des champs uniques sans index utilisées dans les jointures mais non
déclarées comme clef primaire
- des clefs primaires basées sur des chaînes de caractères
La plupart de ces dérives arrivent généralement quand on veut créer une base
de données "trop proche" de la logique métier ("Un identifiant numérique
auto-incrémenté ? Mais pourquoi faire, on peut utiliser notre code produit
avec 3 caractères a-d sauf pour les produits en promotion qui n'en ont que 2
puis 6 chiffres, un tiret et encore 3 chiffres si le produit à été rajouté
un jour pair, c'est beaucoup plus simple.") ou que l'on ne se soucie pas des
performances (une chaîne de caractères comme critère de jointure c'est pas
les mêmes performances qu'un nombre, même indexée, même limitée).
Une clef primaire numérique auto-incrémentée, c'est :
- positif
- presque gratuit en espace de stockage (juste un entier numérique de
plus par enregistrement, c'est raisonnable)
- plus facile à gérer (pas besoin de gérer soi-même une identifiant)
- mieux pour les performances
- non-intrusif
- négatif
- pas forcément intéressant et / ou lisible pour l'utilisateur final
(mais ça peut se cacher)
Pourquoi s'en priver ?
--
Michel Belleville
--~--~---------~--~----~------------~-------~--~----~
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de
Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse
[email protected]
Pour résilier votre abonnement envoyez un e-mail à l'adresse [EMAIL PROTECTED]
-~----------~----~----~----~------~----~------~--~---
