Bonjour,
Je cherche juste comment définir le champ de clé primaire comme auto-incrémentation. Est-ce que quelqu'un est au courant ?
Harry Potter
Bonjour,
Je cherche juste comment définir le champ de clé primaire comme auto-incrémentation. Est-ce que quelqu'un est au courant ?
Harry Potter
De memoire avec certaines bases, type access tu peux selectionner cette option "auto increment" avec sql je n'ai pas trouve ce genre de choses. J'avais du le gerer moi meme en recuperant la valeur la plus elevee de ma cle et au moment de mon insertion passer en parametre la valeur de la cle + 1....
C'est pas bien long a faire, ca demande 5 lignes de codes de plus.
J'espere avoir repondu a ta question
@+
...houla, pas bieeeeen...recuperant la valeur la plus elevee de ma cle et au moment de mon insertion passer en parametre la valeur de la cle + 1
En sql server, tu vas en mode design, tu mets Identity a yes, Identity seed a 1 et increment a 1...
pis ca y'est, tu as ton auto-incrementation...
apres, en Oracle, tu dois faire des triggers, si je me rappelle bien...mais dans l'ensemble, tu dois avoir moyen de faire ca sur toutes les sgbd![]()
Une remarque générale sur les champs auto-incrémentés : je comprends qu'on l'utilise si on en a absolument besoin, mais, dans l'absolu c'est rare.
Personnellement, surtout si le SGBD cible du projet est Sql Server, je n'utilise presque jamais de champs auto-incrémentés et préfére utiliser en clef primaire pour ce type de cas un champs "uniqueidentifier" (dans lequel on stocke un GUID).
Le seul inconvénient de cette méthode est l'impossibilité d'utiliser ce champs dans une clause ORDER ou dans un sort pour lister les entrées créées dans l'ordre où elles l'ont été, mais un champs Timestamp ou date/time en plus sur la table permet de contourner le problème.
L'avantage que présente l'utilisation de l'uniqueidentifier est que l'on peut instancier l'objet métier qui sera ensuite écrit "as is" dans la base sans avoir à s'occuper de concurence d'accés, et sans avoir à récupérer une information "a posteriori" (donc, on peut ensuite confier la tâche de persistance en mode "lazzy" à une entité applicative, sans avoir à réinterroger cette entité applicative pour savoir la valeur qu'aura prise la clef primaire).
Attention : je ne dis pas qu'il ne faut jamais utilisé les séquences/champs auto-incrémentés, etc ... mais simplement qu'ils ne constituent pas toujours la solution la plus simple même si elle saute (un peu trop souvent à mon goût) aux yeux comme solution évidente.
Vaste débat : http://sql.developpez.com/clefs/#L2
J'approuve les arguments que vous avancez, et tout le monde est d'accord sur le fait que l'existence d'une contrainte unique "métier" est indispensable.
Cela dit doubler cette contrainte unique par une clé primaire numérique type identity ne me choque pas du tout, et me réjouit même sur de gros schémas en apportant de réels gains en terme de performance et de stockage.
Pour les GUID, je suis assez d'accord, ca presente pas mal d'avantages (tu peux faire des fusions entre bases sans risques, meilleures perf...)
Par contre, va vendre ca a ton chef qui "fait" des bases de donnees depuis 15 ans (et auquel t'as déja eu beaaaaucoup de mal a expliquer les formes normales)..je te souhaites bon courage
En fait, perso, le gros desavantage que je vois aux GUID, c'est que si tu dois faire "Select * from table where fk_toto = '05a6eeba-ae1b-11dc-8314-0800200c9a66'"....bah tu pleures...![]()
En général, mes clients ne discutent pas mes recommandations. (je confesse que c'est parfois un peu plus dur avec les DBA, mais avec un peu de temps, on arrive à les mettre au pas).
Pour info, je "fais" aussi de la base de données depuis plus de 15 ans; c'est bien pour cela que j'exprime ma position supra
Désolé, mais le cas ne se produit jamais a priori (ou alors, le design de ta DAL -entre autre - est à revoir de A à Z).En fait, perso, le gros desavantage que je vois aux GUID, c'est que si tu dois faire "Select * from table where fk_toto = '05a6eeba-ae1b-11dc-8314-0800200c9a66'"....bah tu pleures...![]()
Bonjour All,
Hé ben dis donc, je vois que j'ai trouvé le sujet à discussion.
En tout cas, merci Nico (même si ta solution a été beaucoup critiquée), merci Pvaliatte, merci Bluedeep !
Bien que je n'ai pas trop trouvé comment vous avez pu faire...
Pvaliatte, je vois pas où t'as vu ce identity, quand je vais dans la table (comme pour rajouter des champs), j'ai bien regardé mais non y'a pas. Sauf peut-être le truc où c'est marqué 'Est d'identité' et où il faut mettre oui ?
Bluedeep, par contre, j'ai déjà essayé ton truc du uniqueidentifier, mais il me met un message d'erreur (Zut, je voulais vous le montrer en retrouvant uniqueidentifier, mais je sais plus où j'ai vu cela déjà, arf...). Mais toute façon, je n'ai pas réussi à le faire marcher.
Et Nico, finallement, j'ai essayé de faire un truc "mano" comme toi, parce que sinon je me serai peut-être trop pris la tête. J'ai donc réussi comme ça à faire une auto-incrémentation, ou une sorte d'auto-incrémentation...
Harry Potter
Dernière modification par Invité ; 19/12/2007 à 13h44.
Bon ca marche ca te permet de tester tes fonctions, masi penche toi sur les methodes d autoincrementation ci-dessus car c'est quand meme mieu niveau securite et surtout si tu comptes tout gerer a la mano tu dois prevoir le cas ou plusieurs utilisateurs veulent se connecter et inserrer en meme temps des donnes.... C'est pas evident alors que si sql gere tout seul, hop plus de prob
@+
Hello!
J'ai choisi l'option de pvialatte (clic sur identity à yes, et Identity seed a 1 et increment a 1 mais quand je souhaite faire un enregistrement, ça m'indique que la colonne en question (qui est la clé primaire) n'accepte pas de valeur nulle...
il me manque quelque chose?
Merci d'avance pour vos contributions.
Partager