Discussion :

[rouba27]

Voilà, je suis débutante en base de données Delphi et j'ai un problème avec une table. Je ne sais pas si je suis sur la bonne voie, c'est pour ça que je veux bien un aide de votre part.
J'ai une liste de 10 produits (par exemple : café, riz, tomates...) dont je dois entrer la valeur moyenne mensuelle (janvier, février , mars, avril...) pour l'année 2016 et 2017, 2015 par zone ( zone 1 , zone 2 … zone 5).
Alors mon application doit afficher un histogramme des prisx par zone et par produit durant toute l'année. Je veux dire que j'entre le produit et la zone, et qu'alors il me donne un diagramme (prix, mois).
J'ai constitué une seule table produit (id , nom produit, prix, mois, année, zone ) mais dans la table il y a beaucoup de redondances. ALors, que dois-je faire ?

Exemple :
riz janvier 100 zone 1 2017
riz février 150 zone 1 2017
riz mars 150 zone 1 2017
.....
riz janvier 100 zone 2 2017
riz février 150 zone 2 2017
riz mars 150 zone 2 2017
...
café janvier 100 zone 1 2017
café février 150 zone 1 2017
café mars 150 zone 1 2017

[SergioMaster]

Bonjour,

Delphi peut gérer des données contenues dans des base de données mais il ne faut pas mélanger Delphi : Pascal et BDD architecture de base de données.
Autre point indiquer le type de SGBD est important certaines ne sont pas aussi performantes que d'autres, s'agit-il d'un SGBDR ou pas ?

Une seule table, c'est non, il faut une table PRODUITS(ID_PRODUIT,NOM_PRODUIT) peut être une Table ZONES (ID_ZONE,NOM_ZONE)
et une table PRIXMOYENS(ID_PRODUIT,ID_ZONE,AAAA,MM,PRIX) (bien sûr sans intitulé du mois).
Contraintes
les ID_ sont des entiers pour chaque table UNIQUE NOT NULL (PRIMARY KEY), il y a bien sur des dépendances (FOREIGN KEY) entre la table PRIXMOYENS et les 2 tables produit et ZONES. Le fait de rajouter la contrainte de dépendance permet aussi d'indiquer comment sera géré une suppression dans les tables PRODUITS ou ZONES
Les NOM_ sont des chaines de caractères à l'occasion pouvant être indexées de façon unique également

C'est la plus "atomique" façon de faire !


Maintenant, si vous trouvez que cela fait encore beaucoup trop d'enregistrements pour prix moyens, si il n'y aura jamais plus de 5 zones alors (là les architectes de bases de données vont me maudire et dire que c'est une hérésie) vous pouvez établir une table ainsi PRIXMOYENS(ID_PRODUIT,AAAA,MM,PZONE1,PZONE2,PZONE3,PZONE4,PZONE5)
mais du fait de la non "atomicité" il sera beaucoup plus difficile de coder l'exploitation des données. Comme on n'est plus au temps où chaque octet comptait pour le stockage je déconseille fortement cette approche.

[popo]

Maudit soit-tu !
C'est une hérésie !

Plus sérieusement...
Comme le fait remarquer SergioMaster à juste titre, passer par la table ZONES fait 5 fois plus s'enregistrements dans PrixMoyens
En revanche ça t'ouvre d'autre possibilités que tu n'aurais pas autrement :
- permet d'être plus souple (si un jour le nombre de zones évolue)
- offre une possibilité d'extension du modèle (si un jour on te demande de stocker des infos sur ces zones).
- permet une meilleure indexation