Discussion :

[nicotine002]

Bonsoir,

Voilà je pose cette question dans un cas bien particulier biensûr
J'expose ma situation:

Une table Fournisseur dans ma base(contenant un auto-increment) va être de plus en plus importante avec le temps, mais vraiment plus importante.
Je me demandais si je devais vraiment creer cette table, car le traitement va de venir de plus en plus long...
Serait-il plus judicieux de creer un xml pour chaque fournisseur et d'y inserer les données?
Le traitement serait-il beaucoup moins long?

Je débute un peu en "tout" donc si je dis des bétises, n'hésitez pas à me le dire

Merci d'avance.

[DBProg]

Salut !

En fait il faut te dire que les SGBD sont créés pour stockés des données importantes. Tu sais il y a des tables qui possèdent parfois des milliers, voire des centaines de milliers d'enregistrements (lignes), donc ça ne posera pas de soucis ne t'inquiètes pas

Mais tu n'as pas spécifier le traitement que tu voulais en faire. Peut-être pourrais tu donner un peu plus de détails...

Je pense que XML est plus une normalisation de transfert de données, pas réellement de stockage. C'est mon point de vue, je n'ai encore pas eu de bdd à stocker dans un fichier, et je n'en ai encore pas connu.

[nicotine002]

En fait c'est un Bd embarquée(HSQLDB).

Les seule operations qui pourraient être effectuées sur le fichier XML sont des recherches et des insertions via la lib JDOM de java.
Et donc si je mettais ces données dans une table HSQLDB, ca seraient des SELECT et INSERT.

Donc en gros :

-Soit je creer une table dans HSQLD "Fournisseur" qui contiendra tout les achats auprés des fournisseurs(ca pourra monter à des dizaines de millier d'enregistrements je pense voire presque des centaines)

-Soit je cree une table pour chaque fournisseur, donc je dois implémenter une gestion dynamique de la creation de table suivant la création de fournisseur.

-Soit je creer un fichier xml pour chaque fournisseur(environ 5/10000 enregistrments par fichier)


Donc ma question est de savoir quel est dans ces 3 choix, celui qui fournira les réponses les plus rapides, sachant que ca sera des trucs basiques,INSERT,DELETE,UPDATE,SELECT dans la base HSQL.

[DBProg]

Quoi qu'il en soit je penche pour la solution base de données. Par contre, le fait que ce soit stocké dans un fichier (HSQLDB), c'est un choix personnel ou imposé ? L'application sera donc monoposte alors ?

Tu parles tout le temps d'une seule table, mais j'ai l'impression que plusieurs tables seraient nécessaires dans ton cas. Dans ta table Fournisseur tu veux stocker les achats. Ce serait bien de stocker les articles, les fournisseurs et une table qui sera l'association des deux avec les commandes (au minimum).

Tu as déjà fais un peu de base de données ?

[nicotine002]

Oui HSQLDB est imposé et l'application est monoposte.

Mais si vous connaissez une meilleure BD embarquée pour un nombre important d'enregistrment, je suis preneur

Sinon j'y ai repensé un peu plus tard et en fait j'avais tourné le problème dans le mauvais sens.

Je voulais creer une table fournisseur qui receverai tout les achats auprés des différents fournisseurs.

Mais en fait dans ma base, j'ai une table Stock, je peux donc lui rajouter un champs contenant le nom du fournisseur.
Et je creer quand même ma table fournisseur mais qui recevra cette fois ci les informations relatives au frounisseurs et rien d'autre.
Comme ca je pourrais joindre ces 2 tables(clé primaire=nom_fournisseur) afin de connaitre tout les achats d'un fournisseur.

Mon raisonnement est-il bon?

Sachant que maintenant la table fournisseur ne recevra que quelques enregistrements, environ une dizaine. C'est peut-être pas peu pour creer une table non?là il vaudrait peut-être mieux que je creer un XML pour chaque fournisseur car creer une table pour 10 enregistrements, ca n'en vaut peut-être pas la peine?


Merci d'avance.

[DBProg]

Je pense qu HSQLDB est très bien. Certainement pour ça que c'est le moteur utilisé OOo Base.

Pour la question de modélisation, je pense que tu devrais lire le cours Merise, tu verras les choses beaucoup plus clairement après.

Je pense que les tables Fournisseur, Article et Achat suffiraient dans ton cas.

Code :

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

1
2
3
4
 
Fournisseur(idFourn, libFourn, descFourn, ...);
Article(idArt, libArt, descArt, ...);
Achat(idArt, idFourn, quantite, date);

Par exemple

[nicotine002]

Ok merci, en gros c'est ce que j'ai comme table à part les nom:

Code :

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

1
2
3
4
 
 
Arcticle--->Argus
Achat--->Stock Neuf et Occaz

C'est pour ca que je voulais rajouter un champ id_fourn dans la table stock

Je vais donc allez voir ce cours,

encore merci

[nicotine002]

Ah bah non ca va encore poser problème,prenons ton exemple:

Code :

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

1
2
3
4
 
Fournisseur(idFourn, libFourn, descFourn, ...);
Article(idArt, libArt, descArt, ...);
Achat(idArt, idFourn, quantite, date);

Achat d'un article chez fournisseur_1
Achat du même article chez fournisseur_2
Ici la je dois mettre à jour la quantité mais je met à jour là quantité où?chez le fournisseur à qui j'ai acheté l'article?Mais dans ce cas la clé(idArt) n'est plus bonne..

Comment je pourrais résoudre çà?
Ou alors je stipule dans idFourn que l'on peut mettre plusieurs fournisseur, mais il faudra que je réalise un vérification à chauqe ajout.

[DBProg]

Pas trop compris le problème en fait ! Qui a dit que la clé de la relation Achat était idArt ? Personne
La clé est double, c'est idArt, idFourn.

Mais pour être plus clair je rajouterai une entité commande.

Code :

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

1
2
3
4
 Fournisseur(idFourn, libFourn, descFourn, ...);
Article(idArt, libArt, descArt, ...);
Commande(idCom, dateCom, ...);
Achat(idCom, idArt, idFourn, quantite);

Si tu dois faire une mise à jour sur un produit dans une commande tu as simplement à faire :

Code :

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

UPDATE Achat SET quantite = newquantite WHERE idCom = nocom AND idArt = noart AND idFourn = nfourn;

Dans ce cas la clé devient bien sur les trois identifiants. Je te livre ça comme ça, n'oublie pas que je ne connais pas du tout tes besoins !

[nicotine002]

Donc là si je veux connaitre le stock d'un article, je fais un:
SELECT quantité FROM Achat WHERE idArt=new article;
et je fais la somme des quantités.
C'est ca?
A quoi servirai l'entité commande?

[DBProg]

Code :

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

SELECT SUM(quantite) FROM Achat WHERE idArt= larticle;

Mais le mieux serait encore de stocker un attribut dans un la table Article, qui se met à jour à chaque commande.

J'ai rajouté une table commande, pour être plus clair en français. C'est pour la modélisation, et ça évite la redondance de l'attribut date dans la table achat, puisque regarde il a été déplacé dans achat.

[nicotine002]

Ok Merci
Je vais regarder du coté des "attribut" car je sais pas trop ce que c'est mais le stock peut aussi bien augmenter que diminuer,je sais pas si ca pose problème...

[DBProg]

Pas forcément. Mais je te conseille vraiment de prendre le temps de lire la documentation sur les bases de données sur le site. Tu comprendras ce que tu es en train de faire là. C'est important de comprendre ce que tu fais, c'est même primordial pour progresser.

[nicotine002]

Bon ca y'est j'ai lu un peu et je me suis mis au MCD...
Je n'arrive pas réellement à creer ce MCD, j'ai du mal à trouver les bonnes tables.
Je vais essayer de te décrire le mieux possible mes besoins.
C'est un organisme de vente:
-Les client peuvent acheter du neuf ou de l'occasion
-Il y a plusieurs fournisseur qui eux même fournissent du neuf ou de l'occasion
-Les artciles peuvent donc avoir un prix neuf et un prix occasion
-Il faut que je puisse manipuler à peu prés tout afin de tout pouvoir afficher
-Les articles comportent un ID unique et un codebarre(pas unique).

Je pense que c'est tout, si tu pouvais m'aider...
Je vais essayé de faire tout ca du mieux possible.

Merci d'avance.

[nicotine002]

Ca y'est j'ai fini mon MCD et ca tourne plutôt bien
Me reste un dernier problème, qui concerne toujours les fournisseurs, même avec ce que tu m'a donné je vois pas comment trouver la solution:

Comment savoir quels ont été les achats envers tel ou tel fournisseur sachant que les quantités varient, on ne peut pas savoir combien d'article ont été acheté à ce fournisseur?

[DBProg]

Salut !

Si bien sur tu peux retrouver quelle quantité a été acheté à un fournisseur. Voici la requête :

Code :

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

1
2
3
4
5
SELECT F.libProd, F.quantite
FROM Fournisseur F
JOIN Achat A ON F.idFourn = A.idFourn
WHERE F.libFour ="Mon fournisseur"
GROUP BY F.libProd, F.quantite;

Mais je ne suis pas sur d'avoir bien compris ce que tu voulais retrouver. Cette requête te sort un état de tout ce qui a été acheté par founisseur avec les quantités. Tu peux rajouter la date comme ça tu n'auras pas tous les mêmes articles ensemble (si tu as besoin de la date).

[nicotine002]

Oui ok c'est de ma faute, je t'ai pas tout précisé.
Un fois l'achat auprès du fournisseur effectué, cet artcile peut être revendu.
Le stock de cette article diminue donc.
Mais j'ai trouvé une solution en m'inspirant de la tienne

[DBProg]

Parfait alors

[Monstros Velu]

Code :

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

1
2
3
4
5
SELECT F.libProd, F.quantite
FROM Fournisseur F
JOIN Achat A ON F.idFourn = A.idFourn
WHERE F.libFour ="Mon fournisseur"
GROUP BY F.libProd

pour avoir la quantité par produit pour un fournisseur