Discussion :

[$grm$]

hellooooooooo,(et vi c'est encore moi)

savez vous si pgadmin permet de créer un systeme d'auto-incrementation sur une clé primaire??? Il parait évident que oui et pourtant .... je ne vois vrt pas où c'est géré!! du coup j'ai essayer de faire un ALTER TABLE et de rajouter à la fin de mon champs "auto_increment" il n'en a pas voulu non plus donc.....

AU SECOURRRRRRRRRRRRRS SVP

[Krapulax]

Salut,

En cherchant un peu, la solution est dans la doc de postgresql :
8.1.4. Serial Types

L'auto-incrémentation est en fait un type de données, comme int ou varchar. Donc, lors de la création de ton champ, dans la liste déroulante "Types de données", tout en bas, tu trouveras le type "serial".

@+

[$grm$]

merci bcp krapulax, je sais pas comment ca se fesse mais j'ai un peu de mal a trouver ce que je cherche sur le site... en tout cas le probleme est resolu déormais

Have a good day

[Bouboubou]

Attention concernant le "type" serial. Il est là uniquement pour des questions de portabilité des applications qui viennent d'ancienne version de Postgres. C'est voué gentillement à disparaître. Dès lors, il faut utiliser les séquences:


Créée une séquence:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
CREATE [ TEMPORARY | TEMP ] SEQUENCE seqname [ INCREMENT increment ]
    [ MINVALUE minvalue ] [ MAXVALUE maxvalue ]
    [ START start ] [ CACHE cache ] [ CYCLE ]

affecte la à ta valeur par défaut de ton id.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
create table orientation (
id                   int            not null default nextval('sIdOrientation'),
idfiliere            int            not null,
abreviation          varchar(20)    not null,
nom                  varchar(20)    not null
);

et puis ensuite tu l'utilises dans les insert comme le type serial. L'aventage, c'est que c'est portable, plus propre et que tu peux remettre à jour l'état de ta séquence(setval) ou la consulter quand tu veux (currval).

Vraiment, je te conseil de les utiliser...

[Krapulax]

Effectivement, tu as raison. De plus, je viens de remarquer dans PgAdmin qu'il y a une section appelée "Sequence", juste aussi de "Tables" où tu peux définir justement ce dont on vient de parler.

@+

[$grm$]

ok bah tu as raison je vais opter pour la gestion des sequences!!!!
je suis entrain de decouvrir tout ca, je n'en avais js entendu parlé avant mais faut dire que j'ai le nez dans les base de données depuis peu!!!

grace mille

[$grm$]

nouvelle question toujours dans la meme branche, pensez vous qu'il y ai un moyen de créer une clé qui commence par AA0001 et qui s'incrémente de la maniere suivante:

AA0001
AA0002
AA0003
..........
AB0001
AB0002
..........
ZZ9999

une auto-incrementation alpha numérique en fait, le probleme est qd je crée ma sequence la valeur min est forcement un chiffre et valmax de meme..... meme en mettant une valeur type autre que integer.....

[Krapulax]

Un petit détour par la doc de CREATE SEQUENCE m'a appris qu'une séquence est en fait un bigint, donc pas d'alphanumérique.... Par contre, dans ton application, rien ne t'empêche de faire une fonction pour passer de 11234 à AA005 (si il y a un lien logique)...

[Bouboubou]

Effectivement les séquences sont uniquement numérique. Mais il faut savoir qu'un identificateur alphanumérique est nettement moins performant au niveau des jointures qu'un identificateur numérique. Des petits détails qui peuvent avoir leur importance dans certain cas.

[$grm$]

oki merci bien, ne connaissant pas trop les fonctions je pense que je vais dissuader mon boss d'utiliser ce systeme , 'il voulait uiliser ce systeme pour un soucis de lisibilité.... mais bon, ses commerciaux feront un ptiti effort!!!

[Krapulax]

Tu peux aussi se créer une table à part avec comme clé primaire ce numéro d'auto-incrémentation que tu auras recopier, et en face la correspondance "XX0011". Comme cela, tout le monde est content !

[$grm$]

génial comme ca tout le monde il est content, encore merci à vous, vous m'avez été d'une aide tres appréciable

[Bouboubou]

Je ne suis pas totalement d'accord avec Krapulax...

Comment veux-tu garder la cohérence entre tes deux tables? Faut écrire des trigger? De plus si tu fais cela sur une seule table (ajout d'un deuxième attribut qui fait partie de la clé) tu n'es pas en 2FN (2ème forme normale). Attention, attention,... bcp de personne disent que les formes normales ne servent à rien, mais souvent ils se mordent les doigts un peu plus tard.

$grm$: franchement, je ne comprends pas pourquoi ta clé primaire doit-être "lisible". Il ne faut pas confondre conception et ergonomie de ton application. Lorsque tu conçois ton modèle EA, ne pense pas à tes futures interfaces graphiques. Maintenant pour répondre à ta question, et après j'arrête de poster des msg car tu l'as mis ton post comme résolu (promis ), si tes lettres alphabétiques en début de ta clé étaient là pour catégoriser ou dissocier tes enregistrements dans ta table, utilise des flags ou d'autres attributs. Rien t'empêche de faire cela. Au moins se sera clair. Ne laisse pas des personnes (manager ou commerciaux) qui connaissent rien en informatique te dicter un comportement, car lorsqu'il y aura des problèmes ils vont te retomber dessus en disant que c'est toi le spécialiste.

Enfin c'est mon avis et cela n'engage que moi!

[Krapulax]

Il est vrai que l'avis de Bouboubou est beaucoup plus sage (et surtout plus juste d'un point du vu conception) que le mien.

Maintenant, cela dépend de ton degré de complexité de ton application. Je ne suis pas pour mettre en place des camions de 30T pour transporter un petit pois.

Ce qui est clair, c'est que tu dois rester maître des moyens à mettre en oeuvre pour arriver à ton but.

[Bouboubou]

Maintenant, cela dépend de ton degré de complexité de ton application. Je ne suis pas pour mettre en place des camions de 30T pour transporter un petit pois.

Oui je suis d'accord avec toi! Faut voir le problème! Je me suis p-ê un peu emballé, mais c'était juste pour donner mon avis.

[$grm$]

bon tout d'abord merci de prendre le temps d'etudier mon cas lol
Et tout ce que tu mets m'interesse bcp donc je vais enlever resolu !!!!!

En fait j'explique un peu plus, c'est un depot vente et on s'est mis d'accord sur le fait que la clé primaire des articles seraient composé d'un code artiicle (type: AA0000) et d'un id deposant (soit la clé primaire de ma table deposants), l'objectif est que lorsqu'on regarde l'article on puisse savoir qui est le deposant en lisant l'etiquette (un id_deposant composé en partie de ses initiales)........voila pour le systeme que je souhaiterais mettre en place!!!!!!

donc un id article serait par exemple:

"JFDURAN AA0001" ce qui veux dire Jean_francois Durand a deposé un article...
"MASSAIN AA0052" ce qui veut dire Marc Assain a déposé 52 articles.....

vous allez me dire ms tu peux faire des requetes pour savoircombien il a vendu d'articles truc muche, vi mais la c'est lisible directement sur l'etiquette!!!!!!

Pourquoi mettre en place un systeme aussi relou, la raison premiere est la suivante, le prog va devoir gérer les commerciaux en deplacement, il va dc falloir faire une version portable de l'appli, la meilleur facon qu'on a trouvé pour que ce commercial ne crait pas un id article sur son portable qui sera le meme que celui qu'il yaura sur le serveur (car qd il est en deplacement on continue a vendre...) c'est de faire un id en fonction de la personne, car la personne ne pourra pas etre chez elle et en meme temps entrain de deposer un article......voilou le probleme....en fait le commercial en deplacement fera une replication en rentrant à l'entreprise.

Mtt je vais passer pour une grosse pillule mais c'est quoi excactement ton systeme de flags, attribut?????

Ne t'en fait pas pour la gestion du projet on ne me dicte aucun comportement seulement cela fait partie des besoins de l'utilisateur final et si c'est faisable c'est normal que je le traite, c'est pour cela qu'on me paie

[$grm$]

vi enfin bref comme je disais c'est pas tres simple tout ca
je le remets en résolu