Discussion :

[say]

Bonjour,
je tente cette question sur ce forum mais j'ai un doute, alors excusez moi d'avance.
Voila, je reconçois un système qui était sous Access. Le choix du SGBDR remplaçant, ça va. En revanche, mon administrateur réseaux me demande de lui donner la volumétrie de la future base. Donc d'estimer l'espace de stockage qui sera nécessaire pour la future appli.
Or j'ai beau cherché des méthodes de dimensionnement, je reste vainement bloqué.
J'avoue qu'à part contruire le dictionnaire de données dans son ensemble , d'évaluer le nombre d'enregistrements à terme et de multiplier par le codage de chaque type de données, je vois pas comment m'y prendre.
Quelqu'un pourrait-il m'orienter vers un méthode, un site?

Merci d'avance

[Fabien Celaia]

Tu peux le faire un niveau conceptuel avec PowerAMC : pour chaque entite, tu peux rentrer le nombre d'occurence appriximative, et il va t'estimer l'espace necessaire.

Sinon, c'est tes dependant du type de SGBDR, de son utilisation (OLTP ou DSS)...

Ce que tu peux faire, c'est partir de ta base Access qui devrait deja te donner une idee de la volumetrie.

[say]

Quand tu dis partir de ma base Access, je saisis pas bien.
En utilisant la taille des fichiers DATA? (La base est en réseau...)

Et sinon, il n'existe pas une méthode plus ou moins standardisée qui permette d'avoir une idée sans passer par un logiciel commercial, même si les résultats sont à moduler par le choix du SGBD?

[laffreuxthomas]

Ce que tu disais c'est bien aussi : multiplier le nombre de lignes par la taille d'une ligne.

[say]

Ok, ça me paraissait un peu simpliste mais je vais faire avec ça pour l'instant.
Ben je suis bon pour le finir rapidement mon dico )

si qqun est inspiré, je suis ouvert à toute suggestion!
tch'o

[qi130]

La taille de la BD dépend aussi de
1/ la taille de chaque page
2/ la taille de chaque ligne
3/ du PCTFREE dans chaque page
4/ du FREEPAGE

Il faut aussi compter avec les index déclarés

[SQLpro]

Comme le dit fadace, il existe des outils pour cela. AMC Designer le fait très bien à partir d'une volumétrie de ligne.

En effet les index prennent une palce difficilement calculbale si l'on ne connait pes leurs structure. Il arrive même que certains index dépssent en volume les simples données de la table.

A +

[temoanatini]

Ca dépend aussi (et peut-être dans certains cas plutôt) du type de données dans la base.

Par exemple, si on y stocke beaucoup de données de type char (varchar etc.), alors là c'est dur de prévoir (qui plus est si la taille des champs est relativement grande et qu'on y insère des chaînes de taille souvent très variable).

[fsmrel]

Concernant les données de type CHAR, VARCHAR et apparentés, si ces données sont nombreuses et si le SGBD les compresse (tables et index, comme par exemple avec DB2 for z/OS), l'estimation qu'on aura faite sera en général largement supérieure à la réalité (j'ai donné). Le mieux est de faire des jeux d'essai permettant d'extrapoler à partir des résultats fournis par le SGBD et de se rapprocher du mieux possible, espérons-le, de ce que sera la réalité.