Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Shop Recherche
1561 connectés 

  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  [SGBD] Structure d'une (grosse) base de données

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[SGBD] Structure d'une (grosse) base de données

n°478715
Circenses
Posté le 06-08-2003 à 07:20:40  profilanswer
 

Imaginez une base de données référencant quelques dizaines de milliers de produits. Chaque jour, chaque produit voit son prix varier.
 
Comment organiser au mieux l'ensemble de ces données, sachant qu'on désire *tout* sauvegarder ? (Est-ce possible déjà ? :??: )
 
Précision : le nombre de produits augmente tous les jours de quelques dizaines d'unités. [:joce]


---------------
www.hattrick.org | France | Championnat | Kastelin (46947)
mood
Publicité
Posté le 06-08-2003 à 07:20:40  profilanswer
 

n°478716
thecoin
Chasseur de chasseur de canard
Posté le 06-08-2003 à 07:26:39  profilanswer
 

:D c'est un peu short comme explication


---------------
Si tu regardes ce que le canard mange, tu ne mangeras pas de canard.
n°478717
pospos
Posté le 06-08-2003 à 07:28:09  profilanswer
 

si la hausse des prix provient d'une formule (car j'imagine que je prix de chaque article n'est pas discuté et augmenté à la main) tu peux à la limite sauvegarder l'augmentation globale pour chaque type de produit (genre +5% le 15 avril sur les produit de type bidule) dans une table et ensuite tu clacul el rpix actuel au moment de la consultation en fonction du prix à une date donnée (dans la table du produit) et des augmentation depuis
 
MAis sinon parcourir chaque jour des dizaines de milliers d'entrée pour augmenter la valeur d'un champs ca parait tout à fait faisable, c'est devrait meme pas prendre tres longtemps...

n°478719
Circenses
Posté le 06-08-2003 à 07:44:07  profilanswer
 

thecoin> Pour être plus clair, on pourrait faire une comparaison avec la bourse : chaque jour, un prix est associé à une action. Il s'agirait donc de mémoriser le prix, chaque jour, pour chaque action.
 
Mais le cas de la bourse est beaucoup plus simple, car le nombre d'action est limité, et relativement constant. Or c'est justement ce nombre et son augmentation journalière qui pose problème. :/
 
pospos> Tu proposes donc de faire autant de table que de produit, et de faire des tuples (date, prix) ? 50.000 tables pour une BD c'est pas beaucoup ? Et c'est pas problèmatique que ce nombre augmente chaque jour ? :??:


---------------
www.hattrick.org | France | Championnat | Kastelin (46947)
n°478724
thecoin
Chasseur de chasseur de canard
Posté le 06-08-2003 à 08:09:47  profilanswer
 

Tu fais une table PRODUIT avec un ID et la description du produit, puis une deuxième table PRIX ou tu as IDproduit, PRIXproduit,DATEprix. Après avecune jointure tu peux soit connaitre le prix a une date donné, soit connaitre le prix pour la derniere date.
Pour la mise a jour du prix sa va dépendre de la règle d'augmentation, si c'est une formule tu peux faire une procédure stocké qui chaque jour va créer les nouveaux prix.
L'historique des prix est-il important?


---------------
Si tu regardes ce que le canard mange, tu ne mangeras pas de canard.
n°478727
Circenses
Posté le 06-08-2003 à 08:19:40  profilanswer
 

Oui l'historique est très important, et c'est d'ailleurs la raison pour laquelle je veux tout sauvegarder.
 
Alors sinon précision supplémentaire, y a aucun traitement sur les données, c'est un simple archivage de données déjà traitées, en vue d'une consultation (et notamment de l'historique).
 
Les seules données à stocker sont :
 
idproduit - prix - date (ex : 25456 - 63000 - 06/08/2003)
 
Y aura évidemnet des trucs en plus à coté, mais ça c'est pas le problème. :)
 
Mais en fait vous êtes en train de me dire qu'une BD de 50.000/100.000 tables c'est pas un problème ? :??: Il me semblait également qu'il fallait éviter de créer des tables à tour de bras dans un bon SGBD...
 
Il faudrait quelle machine pour espérer faire tourner ça convenablement ?
 
Mais si ce n'est effectivement pas un problème, alors je vais directement faire une table pour chaque produit, avec des tuples (date, prix), et en clé primaire la date. :)


---------------
www.hattrick.org | France | Championnat | Kastelin (46947)
n°478745
Mara's dad
Yes I can !
Posté le 06-08-2003 à 08:41:11  profilanswer
 

Circenses a écrit :

Oui l'historique est très important, et c'est d'ailleurs la raison pour laquelle je veux tout sauvegarder.
 
Alors sinon précision supplémentaire, y a aucun traitement sur les données, c'est un simple archivage de données déjà traitées, en vue d'une consultation (et notamment de l'historique).
 
Les seules données à stocker sont :
 
idproduit - prix - date (ex : 25456 - 63000 - 06/08/2003)
 
Y aura évidemnet des trucs en plus à coté, mais ça c'est pas le problème. :)
 
Mais en fait vous êtes en train de me dire qu'une BD de 50.000/100.000 tables c'est pas un problème ? :??: Il me semblait également qu'il fallait éviter de créer des tables à tour de bras dans un bon SGBD...
 
Il faudrait quelle machine pour espérer faire tourner ça convenablement ?
 
Mais si ce n'est effectivement pas un problème, alors je vais directement faire une table pour chaque produit, avec des tuples (date, prix), et en clé primaire la date. :)


 :ouch:  
C'est un troll ou quoi !
 
Il n'est pas question de faire 100000 tables, mais juste 2 !


---------------
Laissez l'Etat dans les toilettes où vous l'avez trouvé.
n°478747
Circenses
Posté le 06-08-2003 à 08:42:23  profilanswer
 

Ha oui j'avais mal lu.  :whistle:
 
Désolé. :D


---------------
www.hattrick.org | France | Championnat | Kastelin (46947)
n°478751
Mara's dad
Yes I can !
Posté le 06-08-2003 à 08:49:49  profilanswer
 

PS : 50000 enregistrements, c'est pas une grosse table pour un SGBD digne de ce nom.


---------------
Laissez l'Etat dans les toilettes où vous l'avez trouvé.
n°478753
Circenses
Posté le 06-08-2003 à 08:52:36  profilanswer
 

Ca va tout de même faire une énorme table de 50.000 x nbjour n-uplets. C'est pas problèmatique, surtout pour faire un historique du prix ?


Message édité par Circenses le 06-08-2003 à 09:03:12

---------------
www.hattrick.org | France | Championnat | Kastelin (46947)
mood
Publicité
Posté le 06-08-2003 à 08:52:36  profilanswer
 

n°478762
Circenses
Posté le 06-08-2003 à 09:07:08  profilanswer
 

(Et au passage, les plus gros SGBD gèrent combien de tables maximum ?)


---------------
www.hattrick.org | France | Championnat | Kastelin (46947)
n°478763
Mara's dad
Yes I can !
Posté le 06-08-2003 à 09:09:42  profilanswer
 

Si tous le prix changent effectivement tous les jours, çà fait plus de 18 millions d'enregistrements par ans.
Il te faut combien d'années d'historique ?


---------------
Laissez l'Etat dans les toilettes où vous l'avez trouvé.
n°478764
Mara's dad
Yes I can !
Posté le 06-08-2003 à 09:10:38  profilanswer
 

Circenses a écrit :

(Et au passage, les plus gros SGBD gèrent combien de tables maximum ?)


Généralement, les limites sont celles du système de fichier.


---------------
Laissez l'Etat dans les toilettes où vous l'avez trouvé.
n°478767
thecoin
Chasseur de chasseur de canard
Posté le 06-08-2003 à 09:15:44  profilanswer
 

C'est koi comme SGBD que tu vas utiliser??


---------------
Si tu regardes ce que le canard mange, tu ne mangeras pas de canard.
n°478769
Circenses
Posté le 06-08-2003 à 09:16:58  profilanswer
 

Mara's dad a écrit :

Si tous le prix changent effectivement tous les jours, çà fait plus de 18 millions d'enregistrements par ans.
Il te faut combien d'années d'historique ?


Dans la pratique ça ne devrait guère excéder deux ans. Mais je pense qu'il vaudrait mieux limiter la taille à quelques mois...
 
Pour 6 mois, ça fait tout de même une table à 10 M d'enregistrements. C'est beaucoup ? Est-il envisageable de reconstituer un historique dans cette table ?
 
NB : je précise qu'il s'agirait d'une BD personnelle, que j'envisage de faire "pour le fun". (Il n'y a donc aucun impératif derrière. :) )


---------------
www.hattrick.org | France | Championnat | Kastelin (46947)
n°478771
Mara's dad
Yes I can !
Posté le 06-08-2003 à 09:17:23  profilanswer
 

thecoin a écrit :

C'est koi comme SGBD que tu vas utiliser??


J'ai tout comme l'impression que c'est pas encore vraiement décidé :D


---------------
Laissez l'Etat dans les toilettes où vous l'avez trouvé.
n°478776
Mara's dad
Yes I can !
Posté le 06-08-2003 à 09:30:11  profilanswer
 

Circenses a écrit :


Est-il envisageable de reconstituer un historique dans cette table ?


Reconstituer un historique A PARTIR DE cette table ? Oui
Reconstituer un historique dans cette table ? Je ne vois pas bien là  :??:


---------------
Laissez l'Etat dans les toilettes où vous l'avez trouvé.
n°478781
Circenses
Posté le 06-08-2003 à 09:35:15  profilanswer
 

thecoin a écrit :

C'est koi comme SGBD que tu vas utiliser??


Je m'orienterais plutôt vers MySQL...
 

Mara's dad a écrit :


Reconstituer un historique A PARTIR DE cette table ? Oui
Reconstituer un historique dans cette table ? Je ne vois pas bien là  :??:  


Je voulais dire A PARTIR DE cette table. ;) Oui c'est possible, mais vu la taille de la table, est-ce *raisonnablement* possible ? C'est là le sens de ma question. ;)


---------------
www.hattrick.org | France | Championnat | Kastelin (46947)
n°478791
tomlameche
Et pourquoi pas ?
Posté le 06-08-2003 à 09:58:21  profilanswer
 

Circenses a écrit :


 
 
NB : je précise qu'il s'agirait d'une BD personnelle, que j'envisage de faire "pour le fun". (Il n'y a donc aucun impératif derrière. :) )
 


 :ouch:  
C'est un troll ?


---------------
Gérez votre collection de BD en ligne ! ---- Electro-jazzy song ---- Dazie Mae - jazzy/bluesy/cabaret et plus si affinité
n°478815
Circenses
Posté le 06-08-2003 à 10:17:39  profilanswer
 

tomlameche a écrit :


 :ouch:  
C'est un troll ?


Non c'est pas un troll...
 
Bon alors je crois que je vais préciser les choses, puisque j'ai un peu mélangé les choses :
 
1) Je n'ai aucune expérience sur les grosses bases de données. Je n'ai aucune idée des moyens à mettre en oeuvre en conséquence.
 
2) J'aimerai savoir si ce que j'ai énonce est réalisable par une entreprise avec les moyens d'une entreprise. (C'est juste pour savoir...)
 
3) J'aimerai *à mon niveau, avec mes moyens et si c'est possible*, réaliser quelque chose de *semblable*, mais pas identique, cad en apportant les modifications qui s'imposent pour que justement ça colle *à mon niveau et à mes moyens*.  
 
Si maintenant vous décidez de faire de mon sujet un sujet "défouloir", amusez-vous comme vous voulez. Je ne l'effacerai pas, vous pourrez même ramenez du monde... :pfff:  


---------------
www.hattrick.org | France | Championnat | Kastelin (46947)
n°478854
tomlameche
Et pourquoi pas ?
Posté le 06-08-2003 à 10:47:51  profilanswer
 

Circenses a écrit :


Non c'est pas un troll...
 
Bon alors je crois que je vais préciser les choses, puisque j'ai un peu mélangé les choses :
 
1) Je n'ai aucune expérience sur les grosses bases de données. Je n'ai aucune idée des moyens à mettre en oeuvre en conséquence.
 
2) J'aimerai savoir si ce que j'ai énonce est réalisable par une entreprise avec les moyens d'une entreprise. (C'est juste pour savoir...)
 
3) J'aimerai *à mon niveau, avec mes moyens et si c'est possible*, réaliser quelque chose de *semblable*, mais pas identique, cad en apportant les modifications qui s'imposent pour que justement ça colle *à mon niveau et à mes moyens*.  
 
Si maintenant vous décidez de faire de mon sujet un sujet "défouloir", amusez-vous comme vous voulez. Je ne l'effacerai pas, vous pourrez même ramenez du monde... :pfff:  
 


Bon, ben si tu veux faire un truc comme ça, la première chose à faire est de rédiger clairement dans un doc type word les fonctionnalités que tu attends de ta BDD. C'est seulement après avoir fait ça que tu pourra envisager une implémentation. Excuse moi si je te parais un peu abrupt, mais j'ai l'impression que tu ne sais pas exactement ce que tu veux faire, et du coup ton truc parait très brouillon.
Si  tu veux apprendre à gérer des grosses bases  de données , tu devrait pouvoir trouver bcp d'idées en fouillant sur le net via le mot clé "datawarehouse".


---------------
Gérez votre collection de BD en ligne ! ---- Electro-jazzy song ---- Dazie Mae - jazzy/bluesy/cabaret et plus si affinité
n°478893
thecoin
Chasseur de chasseur de canard
Posté le 06-08-2003 à 11:23:00  profilanswer
 

Circenses a écrit :


Je m'orienterais plutôt vers MySQL...


 
 [:totoz] Je crois que pour une telle base il te faudra au moins Oracle


---------------
Si tu regardes ce que le canard mange, tu ne mangeras pas de canard.
n°479010
pospos
Posté le 06-08-2003 à 13:26:49  profilanswer
 

Circenses a écrit :


pospos> Tu proposes donc de faire autant de table que de produit, et de faire des tuples (date, prix) ? 50.000 tables pour une BD c'est pas beaucoup ? Et c'est pas problèmatique que ce nombre augmente chaque jour ? :??:


 
mais non mais non!
c'est pas comme ca que ca marche une base de données!!!!!
chaque produit sera un row dans une (ou plusieurs si tu a des trucs à normaliser) tables!
Donc par exemple un table "produit" avec 50000 row, et ca n'a rien d'expetionnel, ca se gere trankil avec mysql

n°479019
jagstang
Pa Capona ಠ_ಠ
Posté le 06-08-2003 à 13:37:50  profilanswer
 

Tu devrais faire d'abord faire une base plus simple. Pour bien comprendre les Bases de données relationnelles. Un petite lecture peut s'imposer pour faire la modélisation
 
A mon avis, une petite bd Oracle doit pesèr 10 GO. Une grande 100 Go


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
n°479021
jagstang
Pa Capona ಠ_ಠ
Posté le 06-08-2003 à 13:39:03  profilanswer
 

encore une chose. Si le prix ne change pas tout les jours, inutile de faire un enregistrement...


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
n°479032
MagicBuzz
Posté le 06-08-2003 à 14:07:15  profilanswer
 

Euh...
 
Unebase contenant autant de produits, avec des produits mis à jours régulièrement implique :
 
-> Un grand nombre de clients
-> Un grand nombre de fournisseurs et de négociants
 
=> Es-tu sûr qu'un prix sera associé de façon unitaire à un produit ?
 
Par exemple, chez GE, ou la base des produits accessoires est bien plus petite (22957 produits) on a des prix stockées dans... 4 tables, pour un total de 9 types de prix différents.
 
Une table de tarifs standard.
-> Le prix corporate (prix appliqué si aucun autre prix n'est applicable)
-> Le prix par établissement (regroupement de zones géographiques)
 
Une table de tarifs à colonne.
-> Un prix dégressif en fonction de chaque établissement
-> Des prix dégressifs en fonction de "barèmes", qui sont paramètrés dans la base client.
 
Une table de tarifs "qui quoi", qui associent à un client ou un regroupement de client, et un produit un prix pour une quantité donnée.
 
Et la table des factures qui contient des devis, des appels d'offres ou des commandes déjà passées par le client, qui sont autant de sources d'infos pour des prix à appliquer.
 
Donc déjà, vérifie que tes prix sont bien unitaires pour chaque produit (ni dégressifs, ni différents d'un client à l'autre)
 
Ensuite, bah... Même une base de 20 Go ça se backup (intégralement, extraction raw) en moins d'une demi-heure... Je vois pas trop l'intérêt de partir dans des délires pour faire du différenciel, ce qui sera énormément plus lent à sauvegarder, et je ne vous parle même pas de la restauration ! (sans compter les risques accrus de corruption de la sauvegarde)
 
Donc un bon lecteur robotisé de DLT, une dizaine de cartouches DLT de 80 Go, et tu peux faire un roulement sur un mois pour tes backup... Y'en a pour 10 K€ à tout casser, n'importe quelle entreprise à les moyens d'investir ça si elle tiens à ces données.

n°483661
toto666
May the force be with you
Posté le 11-08-2003 à 15:46:27  profilanswer
 

Circenses a écrit :

(Et au passage, les plus gros SGBD gèrent combien de tables maximum ?)


 
Tu peux tabler sur environ 50 Millions d'enregistrements
comme max pour mysql et oracle.
 
De toute facon, avec cet ordre de grandeur là, c'est la charge de la machine qui va commencer à donner les limites.

n°483666
toto666
May the force be with you
Posté le 11-08-2003 à 15:49:30  profilanswer
 

JagStang a écrit :

Tu devrais faire d'abord faire une base plus simple. Pour bien comprendre les Bases de données relationnelles. Un petite lecture peut s'imposer pour faire la modélisation
 
A mon avis, une petite bd Oracle doit pesèr 10 GO. Une grande 100 Go


 
L'espace disque est plutot une contrainte pour le sous systeme disque, le systeme de fichier, etc...
pas le moteur SGBD en tant que tel.
Ca serait plutot le nombre de base sur une machine, les enregitrement, le nombre d'instances en memoire....
Il y a une multitude de param.

n°483696
MagicBuzz
Posté le 11-08-2003 à 15:59:45  profilanswer
 

toto666 a écrit :


 
Tu peux tabler sur environ 50 Millions d'enregistrements
comme max pour mysql et oracle.
 
De toute facon, avec cet ordre de grandeur là, c'est la charge de la machine qui va commencer à donner les limites.


Pour Oracle, ça va bien plus loin que ça. Même SQL Server qui est encaisse un peu moins la charge est préconisé en toutes lettres (donc avec support) pour des bases plus grosses.

n°483714
toto666
May the force be with you
Posté le 11-08-2003 à 16:09:34  profilanswer
 

MagicBuzz a écrit :


Pour Oracle, ça va bien plus loin que ça. Même SQL Server qui est encaisse un peu moins la charge est préconisé en toutes lettres (donc avec support) pour des bases plus grosses.


 
En fait, pour le chiffre, je me suis basé sur mySql. :)
De toute facon, quand on arrive a ce chiffre là, on a déja vu monsieur oracle ou madame microsoft venu(e) faire du tuning des bases à la maison :D

n°483957
MagicBuzz
Posté le 11-08-2003 à 19:26:02  profilanswer
 

Juste pour infos, quelques extraits de la doc SQL Server 2000 (Oracle doit logiquement accepter au moins autant)
 
Limitations :
 
Rows per table : Limited by available storage  
Database size : 1,048,516 TB
Databases per instance of SQL Server  : 32,767
Filegroups per database : 256  
Files per database : 32,767  
File size (data) : 32 TB  
File size (log) : 32 TB  
Objects in a database : 2,147,483,647
Objects concurrently open in an instance of SQL Server : 2,147,483,647 (or available memory)  
Tables per database : Limited by number of objects in a database
 
Nombre de processeurs gérés :
SQL Server Enterprise sous Windows 2000 DataCenter : 32  
 
RAM maximum gérée :
SQL Server Enterprise sous Windows 2000 DataCenter : 64 GB
 
On est loin des 50 petits millions de lignes avec MySQL ;)

mood
Publicité
Posté le   profilanswer
 


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  [SGBD] Structure d'une (grosse) base de données

 

Sujets relatifs
[Delphi] Récupérer le nom de la baseArticle: un raytracer de base en C++
[Access] Comparaison de données "hasardeuse"[Résolu] formulaire => données envoyés à fonction php ?
c koi un nombre entier en base octale ou hexadécimale ??Créer un lien dans XSL en fonction de données dans XML
[SGBD] Cherche équivalent ('%query%') pour Access !!![c] : Taille d'une structure != somme de ses élements?
Phpbb et base de données 
Plus de sujets relatifs à : [SGBD] Structure d'une (grosse) base de données


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR