[SQL] - Identifiants

Je réitère…

Bonjour,

Dans une table qui référence des produits, je voudrai savoir s’il est judicieux de mettre en tant que clé primares, les codes produits (ceux-ci sont uniques et sont composés de caractères alphanumériques).

Merci

PS : Je ne sais pas si c’est vraimenjt le bon forum mais comme je me suis fait virer du forum truc en vrac…

bé si il est unique c’est ta clef primaire !

Quelle question bizarre

Koubiiak que oui c’est le bon forum

C’est même un des but de la clé primaire, verifiez au niveau du SGBD de l’unicité de ton code

Dans le cas où ton code produit n’est pas susceptible de changer ni d’être mis à null la PK est une bonne solution.

Dans le cas contraire il est préférable de faire une CREATE UNIQUE INDEX sur ton code produit.

(null interdit dans une PK)

Ce message a été édité par phili_b le 12/03/2004

Bah en fait c’est parce que pour l’instant, il n’y a pas de codes produits et donc les ID des produits sont simplements in INT qui s’incrémente automatiquement. Et je voulais savoir si je remplaçais le ID par code produit ou si je rajoutais un champ code_produit.

…oui je vais me taper toutes les références pour rentrer les codes produits.

[quote]Bah en fait c’est parce que pour l’instant, il n’y a pas de codes produits et donc les ID des produits sont simplements in INT qui s’incrémente automatiquement. Et je voulais savoir si je remplaçais le ID par code produit ou si je rajoutais un champ code_produit.

…oui je vais me taper toutes les références pour rentrer les codes produits. [/quote]oulà! C’est justement à cela que je pensais!

Et dans SQL server on ne peut pas transformer simplement une PK autogénérée en PK avec code mis à la main.

Si tu as déjà une table principale dont les produits sont referencés par une tripotée de table; tu risques de t’amuser à tout refaire.

Je te propose les étapes suivantes.

  • créer une colonne code produit
  • create unique index sur les codes produits
  • et puis c'est fini si tu ne veux pas changer les tables qui référencent
  • Je te propose les étapes suivantes si tu veux changer les tables qui référencent:
  • créer une colonne code produit
  • create unique index sur les codes produits
  • créer une colonne code produit sur toutes les tables qui référencent
  • faire une requête de mise à jour des codes produits sur toutes les tables qui référencent
  • rajouter les contraintes sur les nouvelles colonnes (si existe dans le SGBD)
  • supprimer les anciennes contraintes de références (si existe dans le SGBD)
  • supprimer l'ancien colonne de reference sur toutes les tables qui référencent
  • requête fait rapidement de tête (la syntaxe change entre SQL server et Oracle). Je te sers celle d'oracle.
    UPDATE TABLE_QUI_REFERENCE T1 SET code_produit=   (SELECT  code_produit FROM produit WHERE produit.pk_d_avant=T1.fk_d_avant) WHERE fk_d'avant is not null
    à vérifier (et changer sous SQL server) car écrite rapidement de tête.

    Ce message a été édité par phili_b le 12/03/2004

    [quote]à vérifier (et changer sous SQL server) car écrite rapidement de tête[/quote]Mais non A lancer directement sur le serveur de prod… Comment ca ca merite la peine de mort les commandes a la main sur le serveur de prod? Ha Oui oui d’experience, meme un copier coller d’une commande “qui marche” lancee sur le serveur de prod ca merite la prison a vie.

    les gros sabots de Glop…

    où as tu vu que je disais qu’il fallait le lancer sur le serveur de prod les yeux fermés ???

    On le teste d’abord en dév, en virant l’autocommit, si par malheur il est sur ON, pour vérifier ses données avant le commit, puis après validation on livre le script que l’on a testé en dév sur le serveur de prod (dans une transaction aussi<>autocommit).

    S’il n’y a pas de procédures de livraison et qu’on est livreur et receptionniste, il arrive que dans un monde réel on lance le script en mode transactionnel sans commit, puis on vérifie ses données et enfin on fait le commit.

    édit: heu c’était peut-être de l’humour qui masquait un conseil ? Je suis très premier dégré.

    édit2: ah okéé “Oui oui c’etait de l’humour qui masquait un conseil C’etait tres 3059723eme degre.”

    edit3: J’y penses, puisque l’on est dans le sujet:
    Attention les DDL (data definition language, les ALTER & co quoi) cassent la transaction en cours sur certaines SGBDR où les DDL ne sont pas transactionnel. Dans ce cas là il faut lancer les DDL  avant une transaction ou après pour éviter des mauvaises surprises.

    Ce message a été édité par phili_b le 12/03/2004

    Oui oui c’etait de l’humour qui masquait un conseil C’etait tres 3059723eme degre.

    Bah je croyais que t’avais perdu ton sens de l’humour depuis que tu etais passe sur VisualStudio.net (en tout cas moi : OUI)
    Ce message a été édité par c0unt0 le 12/03/2004

    [quote]Bah je croyais que t’avais perdu ton sens de l’humour depuis que tu etais passe sur VisualStudio.net (en tout cas moi : OUI)[/quote]Tssss Ha bravo! Il est tres bien d’abord mon visual studio 2005 et je ne l’echange pas contre deux barils de visual studio 6. Ha non monsieur!