Primary_key sans autoincrement

Community FR
1

Bonjour,

J’aimerais avoir dans une table une primary_key “id” sans autoincrement.
Quelle est la meilleure solution ?

Faut-il garder “id” comme nom ?
Pour l’instant, j’avais fait un set_primary_key dans le modele et ajouté
une ligne dans ma migration avec :id => false au préalable.:

t.integer :id, :null => false.

Mais je ne sais pas comment lui dire de la mettre en primary key…
Le probleme etant qu’en mettant le set_primary_key dans le model n’en
fait pas une clé primaire de ma table au sens SQL.

Une idée ?

2

S’écarter de la convention peut servir à quelque chose, à condition que
ça
ait un sens, une utilité.

Dans ton cas précis, quelques questions à te poser :

  • à quoi ça va servir ?
  • est-ce que ça ne serait pas plus simple et plus sain d’avoir un
    champs
    unique dans lequel tu puisse entrer ce que tu veux et laisser la clef
    primaire numérique auto-incrémentée tranquille ?

A ta place je commencerais par bien me poser ces deux questions avant de
vouloir appliquer une réponse à ta question d’origine.

Mais admettons que tu aies à exploiter une base de données à la fois :

  • pré-existante
  • dont tu n’as pas le droit de changer l’architecture pour l’adapter
    Ã
    tes besoins

Dans ce cas, je te recommande de d’abord lire cette page de la wiki
rails :
http://wiki.rubyonrails.org/rails/pages/howtouselegacyschemas

Puis prends deux minutes pour considérer la situation. Des fois, il est
plus
simple / rapide / propre de refaire proprement une base pour rails et
faire
migrer les données un grand coup proprement pour la production (et
peut-être
aussi pour le développement, ça peut être une bonne idée d’en faire une
tâche rake) que de s’ennuyer à exploiter une base qui va te forcer Ã
refaire
beaucoup de travail qui serait déjà fait en respectant les conventions.

–
Michel B.

3

Tu as raison. J’avais fait une première tentative avec une colonne id
autoincrémentée, dans les règles et j’avais mis dans une seconde colonne
ma valeur integer.

En fait, j’ai lu la page du wiki. Mais, je suis d’accord avec toi quand
tu dis que c’est plus simple et rapide d’avoir un id classique rails,
unique, autoincrémenté et nommé id mais par contre pas forcément plus
propre au sens base de données (pas au sens rails)

Mais en fait, si l’on a déjà dans un cas, une colonne “metier” de la
table qui sert pour le metier de clé unique d’un enregistrement (et qui
n’est pas autoincrémentée) , je ne voyais pas trop l’utilité d’avoir en
plus une colonne id autoincrémentée à coté sachant que la colonne
“metier” me servait d’identifiant unique de mon enregistrement.

Maintenant, je sais que je suis assez borderline avec les conventions
Rails dans ce cas :slight_smile:

Merci de ta réponse rapide.

4

Le 13 octobre 2008 16:20, Michel B. a écrit :

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.”)

Si jamais les codes ou la nomenclature changent, ça nécessite
de modifier toutes les tables où cette nomenclature est utilisée.
C’est moins gênant si toutes les références entre tables sont
gérées par des clés primaires “classiques”.

-- Jean-François.

–
Les 50 ans du Lisp : http://www.lisp50.org
http://twitter.com/underflow_

5

La plupart de ces dérives […]
Si jamais les codes ou la nomenclature changent[…]

Pour rajouter une couche, je dirais que si Rails a décidé d’appeler sa
clé
“id”, de la faire autoincrémentée, et de le cacher (meme pas besoin de
le
déclarer lors des migrations), c’est que ça couvre 98% des cas (et je
suis
sympa, j’aurai pu dire 99% sans trop prendre de risques (((-; )

gUI

–
Pour la santé de votre ordinateur, préférez les logiciels libres.
Lire son mail : http://www.mozilla-europe.org/fr/products/thunderbird/
Browser le web : http://www.mozilla-europe.org/fr/products/firefox/
Suite bureautique : http://fr.openoffice.org/

6

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 B.