Discussion :

[next_gen]

Hello,

difficile de savoir où cette question a déjà été posée mais j'imagine que je ne dois pas être le seul à me la poser !
Je travaille actuellement sur un système d'archivage assez atypique qui regroupera à terme des données assez hétérogènes les unes des autres avec toutefois des "grumeaux" de données liées. J'utilise MySQL.

D'après vous, est il plus efficace (rapide, sûr, ergonomique) de multiplier les tables (une cinquantaine) dans une base unique ou au contraire, scinder les domaines de données et partir sur plusieurs bases avec des tables plus homogènes ?

Merci beaucoup !

neXt_gEn

[danidan75]

http://sqlpro.developpez.com/cours/m...n/metadonnees/

[next_gen]

Je viens à peine de commencer la lecture de l'article que tu me proposes danidan75 et je suis très enthousiaste !
Je vous tiens au courant

Merci !

[next_gen]

Après une lecture attentive, je découvre une façon particulièrement ingénieuse et performante de répondre à de nouveaux besoins une fois le système mis en place. Très instructif mais pas encore tout à fait ce que je cherche à savoir.

Mon architecture n'est pas encore arrêtée (loin de là), j'en suis encore aux premières étapes de réflexions. Ma question première est posée au sens "général".

Selon vous, démarrer avec plusieurs bases pour alléger le nombre de tables par base est t'elle une méthode valable ?

Merci encore !

NeXt_gEn

[CinePhil]

Selon vous, démarrer avec plusieurs bases pour alléger le nombre de tables par base est t'elle une méthode valable ?

Si c'est pour tout rassembler un jour dans une seule base parce que c'est pour la même application au sujet d'un même domaine sémantique il vaut mieux modéliser correctement une seule BDD.

Mais la description de ton besoin me rappelle un peu l'application sur laquelle je travaillais à l'INRA. Elle était construite autour d'une BDD de métadonnées sur des ensembles de données statistiques et des projets d'études de ces données. Les données statistiques elles-mêmes étaient récupérées de fichiers textes et stockées dans des BDD séparées et à vrai dire le plus souvent même pas modélisées, chaque table de données statistiques étant issue directement d'un fichier texte. Par contre, mon travail avait notamment consisté à reconcevoir la BDD de métadonnées.

Par exemple, si on avait un jeu de données venant d'une étude X, on créait une BDD X et on y importait les données à l'aide de requêtes LOAD DATA INFILE, ce qui créait autant de tables que d'imports. Certaines tables pouvaient alors être fusionnées ou retravaillées avant de servir réellement pour les études faites à l'aide du logiciel.
Dans les métadonnées, il y avait une table 'zone_depot' qui enregistrait les informations relatives aux BDD créées pour l'import des données statistiques, une table (dont j'ai oublié le nom) qui enregistrait les informations sur les tables à l'intérieur des zones_depot, une table (dont j'ai oublié le nom aussi) qui enregistrait la description des colonnes des tables des zones_depot.
On avait ainsi des informations sur des données très diverses dans une seule base de métadonnées mais les données utiles étaient stockées dans les BDD MySQL séparées.