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.

c'est un peu short comme explication

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...

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 ?

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?

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.

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

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

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

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 ?

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

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 ?

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

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

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. )

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

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

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

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.

   
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...  

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".

 
  Je crois que pour une telle base il te faudra au moins Oracle

 
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

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

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

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.

 
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.

 
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.

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

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