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

  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  optimisatiser la structure d'une base de données...

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

optimisatiser la structure d'une base de données...

n°1355855
clems07
Posté le 28-04-2006 à 12:04:04  profilanswer
 

Bonjour à tous!
Après plusieurs recherches sur le forum... je me lance à faire ce nouveau sujet.
 
Voila je dois concevoir une base de données qui est amenait à recueillir un nombre impressionant d'enregistrements...
En effet ce sont des valeurs mesurées par des stations météo...
Jusque la ca va... mais le souci c'est que certaines stations relevent des mesure toutes les minutes pendant plusieurs années... ce qui commence à faire énorme...
 
Je ne m'attarde pas pour le moment sur les objectifs de la base de données. (on verra plus tard si c'est vraiment necessaire!)
 
Ma question est plus générale:
 
Pour accéder a des données lorsqu'on en stock une masse impressionante, est-il plus judicieux de multiplier le nombre de tables contenant peu d'enregistrements ou de garder des tables avec plus de champs et d'enregistrements?
Sinon est ce que construire une base de donnees par année peu etre une bonne solution?
De se fait en terme de temps d'accé, quel est le moins couteux: l'ouverture de la base, la jointure entre 2 tables ou le balayage d'une table?
 
Merci de pouvoir m'éclaircir à ce sujet...

mood
Publicité
Posté le 28-04-2006 à 12:04:04  profilanswer
 

n°1355865
Sve@r
Posté le 28-04-2006 à 12:23:37  profilanswer
 

clems07 a écrit :

Bonjour à tous!
Après plusieurs recherches sur le forum... je me lance à faire ce nouveau sujet.
 
Voila je dois concevoir une base de données qui est amenait à recueillir un nombre impressionant d'enregistrements...
En effet ce sont des valeurs mesurées par des stations météo...
Jusque la ca va... mais le souci c'est que certaines stations relevent des mesure toutes les minutes pendant plusieurs années... ce qui commence à faire énorme...
 
Je ne m'attarde pas pour le moment sur les objectifs de la base de données. (on verra plus tard si c'est vraiment necessaire!)
 
Ma question est plus générale:
 
Pour accéder a des données lorsqu'on en stock une masse impressionante, est-il plus judicieux de multiplier le nombre de tables contenant peu d'enregistrements ou de garder des tables avec plus de champs et d'enregistrements?
Sinon est ce que construire une base de donnees par année peu etre une bonne solution?
De se fait en terme de temps d'accé, quel est le moins couteux: l'ouverture de la base, la jointure entre 2 tables ou le balayage d'une table?
 
Merci de pouvoir m'éclaircir à ce sujet...


 
Conceptuellement, une table doit regrouper l'ensemble des enregistrements de même nature. Surtout qu'à chaque nouvelle table, la structure générale de la BDD s'alourdit "considérablement" (elle contient en interne la table des table, la table des colonnes, la table des index, etc et chaque nouvelle table rajoute des éléments à toutes ces tables internes).
Donc il vaut mieux une seule table pour tous tes enregistrements plutôt que plusieurs tables.
 
En ce qui concerne une bdd par années, ça ne dépend que de ton besoin. Si tes requêtes ne concernent qu'une seule année, ça ira. Mais si t'as besoin d'infos sur plusieurs années en même temps, tu seras obligé d'alourdir ton code pour tout récupérer.
 
T'en fais pas pour le volume des infos. Ca te semble peut-être énorme mais les BDD ont justement été créées pour stocker et rechercher des données en grand nombre. En un an il y a 525960 minutes et si chaque info fait 1/2ko (512 octets ce qui permet de stocker quand-même 64 valeurs au format "double" ), ton poids d'info pour un an ne sera que de 256Mo. Face à la puissance des disques qui travaillent en Go, c'est pas vraiment un poids énorme...


---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
n°1355946
clems07
Posté le 28-04-2006 à 13:57:22  profilanswer
 

merci Sve@r
 
En effet je vais avoir des requêtes concernant plusieurs années...
Donc s'est peut etre pas une bonne solution de faire une bdd par an.
 
Sinon la taile de la bdd sur le disque n'est pas ce qui m'importe le plus...
En fait cette bdd doit etre accessible dans l'avenir sur le net!  
Je cherche donc la meilleure architecture pour que les requètes s'executent le plus rapidement possible...
ne crois tu pas que l'accés a un enregistrement dans une table contenant plusieurs centaines de milliards de lignes risque de prendre du temps?  
(en effet, 20 000 stations faisant une mesure par minute pendant 30 ans = 315 360 000 000 valeurs!)

n°1356396
Sve@r
Posté le 29-04-2006 à 10:29:12  profilanswer
 

clems07 a écrit :

Sinon la taile de la bdd sur le disque n'est pas ce qui m'importe le plus...
En fait cette bdd doit etre accessible dans l'avenir sur le net!  
Je cherche donc la meilleure architecture pour que les requètes s'executent le plus rapidement possible...
ne crois tu pas que l'accés a un enregistrement dans une table contenant plusieurs centaines de milliards de lignes risque de prendre du temps?  
(en effet, 20 000 stations faisant une mesure par minute pendant 30 ans = 315 360 000 000 valeurs!)


 
En général, avec les index, la recherche est très rapide surtout si les index sont construits en arbre (une recherche sur "n" valeurs ne fait que "log(n)/log(2)" comparaisons) mais avec 3Go d'enregistrements, je suis dubitatif (surtout qu'il faut prendre en compte la taille d'un enregistrement)...
Ca semble un projet de haut niveau. Si c'est le cas et qu'il est soutenu par des moyens financiers, tu pourras déporter ta bdd sur un gros calculateur...
 
A ce niveau là, tu peux pas te lancer à l'aveuglette. Faut que tu fasses des tests, que tu génères artificiellement (avec un shell par exemple si t'es sur de l'Unix) tes 3Go d'enregistrements puis que tu les injectes dans différentes bdd pour les évaluer.
 
Bon, j'ai d'ailleurs présumé que tu étais sur de l'Unix (ou apparenté) mais c'est à mon avis indispensable. C'est universellement connu que Unix/Linux est plus rapide que zindoz pour ce genre de travail...


Message édité par Sve@r le 29-04-2006 à 10:37:50

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
n°1356413
moi23372
Posté le 29-04-2006 à 11:24:56  profilanswer
 

c'est pas linux ou unix qui fait la rapidité, mais le type de plateforme. Une plateforme unix est bien plus performante (plus chère aussi) qu'une plate forme PC. C'est de gros calculateur généralement qui sont optimisé pour ce genre de travail. Je ne serais pas convaincu qu'une BDD sous LINUX tournerait plus vite que sur Windows. Absolument pas convaincu la... Par contre entre une plateforme pc et une unix, il n'y a pas photo :D

n°1356420
Sve@r
Posté le 29-04-2006 à 11:48:57  profilanswer
 

clems07 a écrit :

en effet, 20 000 stations faisant une mesure par minute pendant 30 ans = 315 360 000 000 valeurs!


Oui mais la plateforme utilisée évoluera en 30 ans...


---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.

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

  optimisatiser la structure d'une base de données...

 

Sujets relatifs
pb de base de données à free[VBA-E] afficher des données dans des cellules
convertir base de donnée excel en base de donnée SQLAmélioration de la structure des tables - problème d'évolution
Base de donnée locale. Que choisir ?conception Base de donnees
Plusieurs données dans un cookie, possible?Probléme avec une structure
Plus de sujets relatifs à : optimisatiser la structure d'une base de données...


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