Discussion :

[$grm$]

non pas du tout en fait c'est fait pour!!!!! et je te rassure j'ai bien créé un article contenant l'id-deposant (en FK) relié à un id_deposant de la table deposants_tbl existant (en PK) donc qui est le même...

[Bouboubou]

A ce que je sais, l'oid correspond bien au rowid d'Oracle.

Maintenant concernant ta requête, il FAUT absolument que tu aies un clé primaire sur tes tables, j'en vois tjs pas

Fait nous un

Code :

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

1
2
3
\d deposants_tbl
puis
\d articles_tbl

et transmet nous le résultat, stp!

A part cela, ta question relève d'un autre forum

A+

[$grm$]

en fait le probleme n'est pas réellement que j'aie une clé primaire ou pas (meme si je vais en avoir une dans article_tbl mais c'est un peu compliqué car elle sera obtenue grace a une concaténation), c'est juste mon incrémentation de numero qui me pose probleme a l'heure actuelle lol mais je vais aller faire un tour dans la rubrique SQL comme conseillé.

Merci bien à tous les deux

[GeantVert13]

t'as essayé le dernier sql que je t'ai envoyé ?

[$grm$]

vi pardon


depot=# \d deposants_tbl
Table "public.deposants_tbl"
Colonne | Type | Modifications
--------------+-------------------+---------------
id_deposant | integer | not null
cp | integer |
societe | character varying |
nom | character varying | not null
prenom | character varying | not null
adresse | text | not null
pays | character varying | not null
tel_domicile | integer | not null
tel_bureau | integer |
tel_portable | integer |
mail | character varying |
fax | integer |
observation | text |
mdp | integer | not null
blocage | boolean | not null
profession | character varying |
numero | integer |
Index: deposants_tbl_pkey primary key btree (id_deposant)
Foreign Key constraints: FK_cp FOREIGN KEY (cp) REFERENCES cp_tbl(cp) ON UPDATE RESTRICT ON DELETE RESTRICT


depot=# \d articles_tbl
Table "public.articles_tbl"
Colonne | Type | Modifications
----------------+---------+---------------
id_article | integer | not null
id_deposant | integer |
id_geographie | integer |
id_employe | integer |
id_famille | integer |
description | text | not null
observation | text | not null
assure | boolean | not null
cle | boolean | not null
id_fournisseur | integer |
Index: articles_tbl_pkey primary key btree (id_article)
Foreign Key constraints: FK_deposant FOREIGN KEY (id_deposant) REFERENCES deposants_tbl(id_deposant) ON UPDATE RESTRICT ON DELETE RESTRICT,
FK_employe FOREIGN KEY (id_employe) REFERENCES employes_tbl(id_employe) ON UPDATE RESTRICT ON DELETE RESTRICT,
FK_famille FOREIGN KEY (id_famille) REFERENCES famille_tbl(id_famille) ON UPDATE RESTRICT ON DELETE RESTRICT,
FK_geo FOREIGN KEY (id_geographie) REFERENCES geographie_tbl(id_geographie) ON UPDATE RESTRICT ON DELETE RESTRICT,
FK_fournisseur FOREIGN KEY (id_fournisseur) REFERENCES fournisseurs_tbl(id_fournisseur) ON UPDATE RESTRICT ON DELETE RESTRICT

[GeantVert13]

update only deposant_tbl
set numero=numero+1
from article_tbl as a
where a.id_deposant=deposant_tbl.id_deposant
and a.oid=(select max(oid) from articles_tbl as a1
where a1.id_deposant=deposant_tbl.id_deposant)

[$grm$]

oui réponse:

ERROR: Column reference "numero" is ambiguous

[GeantVert13]

Peux tu expliquer à quoi sert le champ numéro, ainsi que le but exact de ton update svp ?

[Bouboubou]

il y a un truc pas logique... explique nous ce que tu souhaites faire, stp!

[Bouboubou]

Comme il peut y avoir pls article par déposant, tu souhaites augmenter de 1 le numéro du déposant qui a enregistré le dernier article à un moment t? C'est + ou - cela?

[GeantVert13]

Je crois que grm est en train de réfléchir à ce qu'il voulait faire, et qu'il ne s'en souvient pas.

Je suis passé par là maintes fois ;-)

[$grm$]

non pas du tout geantvert

ce que je veux faire est créer une clé primaire dans la table article qui sera la concaténation de l'id_deposant et du numéro (que j'essaie d'incrémenter) qui s'incrémante à chaque article rentré (j'ai donc créé un trigger qui appelle la fonction qui doit faire l'update), donc en lisant cette clé primaire vous allez pouvoir savoir combien d'articles a pu deposer "le" deposant!!!! Voila quel est mon bjectif final... si vous avez des idées elles seront plus que les bien venues...

MERCI

[GeantVert13]

la façon de faire me parait bizarre
car tu peux avoir le nombre de depot par deposant avec une simple requete

select count(*) from articles_tbl
where deposant_id=xx

Ca veut dire aussi qu'a chaque fois que quelqu'un dépose un article, sa clé primaire change !!

A mon avis il vaudrait mieux mettre deposant_id en clé primaire tout simplement, et faire une fonction
nb_depot(xx) qui renvoie le nombre de depot du deposant xx, non ??

[Bouboubou]

c'est pas très relationnel tout cela Pourquoi as-tu besoin de cette clé primaire? tu en as déjà une dans ta table article!!! Je suis sûr qu'il y a un autre moyen!

Si tu as besoin de cela, il te suffit de faire un select pour connaître le nombre d'articles par déposant:

Code :

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

1
2
3
4
select id_deposant, count(*) as nbreArticle
from deposants_tbl d, article_tbl a
where d.id_deposant = a.id_deposant
group by id_deposant;

En créant ta super clé primaire, tu es entrain de créer des incohérences dans ta base de données! Si un jour ta clé t'annonce 8 articles pour un déposant mais que tu en 9 dans ta table article_tbl? Que feras-tu? Franchement à mon avis il n'y a absolument rien qui justifie de faire cela. Tout au plus, tu auras à faire un deuxième select.

[Bouboubou]

Je vois que l'on est deux à répondre en même temps... mais les deux du même avis!
A+

P.S: Si je peux me permettre de vous demander d'utiliser les balises code et autre pour le formattage de vos posts, merci d'avance. C'est plus simple à lire.

[GeantVert13]

En effet,

Bouboubou sort de mon corps ;-)

[$grm$]

encore une fois merci bcp de m'aider

donc le pourquoi du comment:

en fait je vais develpper le prog derriere, et ce programme doit donc gérer en partie les depots. Un dépot peut se faire à deux endroits:

- soit au dépot vente (lieu de l'entreprise)
- soit chez un particulier (chez le deposant)

il va donc y avoir une version portable du programme qui devra avoir une bdd portable qui sera synchronisée lors du retour du commercial qui aura été cherhcé les articles et qui les aura rentré dans son ordi ....comment faire pour qu'une clé primaire de la table article ne soit pas créée en double en meme temps chez le deposant et au dépot????

La solution trouvée a été de définir a clé primaire de la table article en fonction du déposant (par exemple contient ses initiales+d'autres parametres) car il ne pourra pas être en même temps chez lui (oui il y a l'enlevement avec le commercial) et au dépot!!!!

jusuqe la vous êtes d'accord oupas ???

[Bouboubou]

A mon avis, ta base de données portable devra contenir des identificateurs différents que ta base de données du dépôt. Lors de la synchronisation tu fais tous tes insert comme si ton commercant avait pris note sur un bout de papier et rentre ses articles de retour au dépôt (simplement cela il ne le saura pas ) Tu as l'avantage d'avoir qu'une centralisation des données.

Les bases de données réparties sont un vaste sujet. Je ne m'y connais pas assez pour te proposer une bonne solution. A ta place, je consacrerai quelques jours à lire un ou deux chapitre d'un livre sur le sujet. Ou pose peut-être ta question sur le forum de modélisation

Voilà

[GeantVert13]

D'accord avec bouboubou,

Perso je vois ça de la façon suivante :
Un programme simpliste pour les itinérants qui ne feront que remplir une bdd très simple.

Une fois de retour à la centrale, importer la base de l'itinérant dans ta base dans des table temporaire et faire un prog qui gère les insert en respectant les contraintes d'intégrité de ta base principale. ensuite une RAZ des tables temporaires et de la bdd de l'itinérant et c'est reparti pour un tour...

[$grm$]

d'accord, vous pensez qu' on pourrait faire de la maniere suivante pour la version portable:

1)créer une clé primaire sur la table article qui s'auto-increment afin de gérer les relations et l'unicité.

2)Lors de la synchro faire un INSERT qui ne prenne pas en compte cette clé primaire "portable" afin qu'elle soit recréée sur la base centralisée?