Bonjour,
 
Je travaille actuellement sur l'extraction et stockage d'indicateur dans un réseau.
Le but étant de pouvoir analyser les performances d'un bout à l'autre de la chaine avec un maximum de granularité. Une chaine pouvant être constitué de N composants.
 
A l'heure actuelle, je n'étudie qu'une partie de ma chaine, donc la base dans laquelle je stock mes données est assez simple, et j'ai une table pour ce composant avec autant de champs qu'il y a d'indicateurs.
 
Je veux aujourd'hui étendre mon étude. Pour celà je dois intégrer des données d'autres composants. Les données sont différentes. Par contre leur identification d'un composant à un autre reste la même (même clef primaire).
 
Je pense avoir 3 choix pour mon stockage de données:
1- Je garde mon modèle actuelle, et je rajoute une table par type de composant, qui contiendront autant de champs qu'il n'y a d'indicateurs à stocker.
2- Je pars sur une seule grosse table qui contiendrai toute mes données. Donc si j'ai 5 composants différents, qui ont chacun 10 indicateurs, ca me fait une table avec 50 champs. Par contre a chaque fois que j'intègre les données pour un composant, je laisse les 40 autres champs vide...
3- Je fait une table qui contient un ID d'indicateur ainsi que son nom et éventuellement le type de composant auquel il se rattache. Je fais une table qui contient la liste de mes composants. et finalement une 3eme table dans laquelle j'ai 3 champs: ID de mon composant, ID de mon indicateur et la valeur de ce dernier (plus d'autre champ pour completer ma clef primaire, tel la date et l'heure...)
 
 
la solution 3 me parait la plus complexe, mais également la plus flexible, car je peux rajouter autant de composants que je le souhaite, ou d'indicateurs, sans pour autant avoir a changer l'architecture de ma base.
Par contre il y a tres forte redondance de données dans la table contenant les données.
 
La solution 1 par contre nécessite des modification / ajouts de tables à chaque nouveau composants / indicateurs. Par contre il y a moins de redondances de données, et les requetes peuvent être beaucoup plus simple.
 
Avez vous une opinion là dessus? Y-a-t-il un nom pour décrire le type de base que je veux faire dans ma solution 3?
 
Merci
 
 

Sans hésiter solution 3)

Même si j'ai plusieurs centaines de millier d'entrées?

la 1ère solution est à exclure.
Les 2 et 3 sont toutes les 2 valables et il faut voir l'utilisation que tu en fais afin de pouvoir trancher. Typiquement la 2ème sera plus rapide à utiliser mais prendra plus de place .. donc à voir de ton côté

 
Oui, une base de donnée c'est fait pour ça

+1 pour la 3ème solution. La 1) n'est pas viable et le 2) pas efficace (sans compter que d'un point de vue modélisation, c'est un non sens).
 
Je l'ai mise en oeuvre dans mon soft Icare (cf ma signature), un soft en GPL de gestion de conf logicielle et matérielle.
 
Bien indexée, la BD tiendra largement la charge. Après, tu peux aussi utiliser le système de partitions de Mysql pour réduire al taille de tes tables si besoin est

 
Pas d'accord. C'est un cas classique de single-table inheritance. Ou alors j'ai loupé une étape  

 
la solution 2, si j'ai bien compris, c'est mettre dans une seule table, tous les champs, en particuliers ceux relatifs aux indicateurs des composants. Or suivant le type de composant, celui-ci n'a pas les mêmes indicateurs. Ca veut donc dire que pour chaque enregistrement, un très grand nb de champs seront vides car n'ont pas lieu d'être rempli pour le composant concerné. par ailleurs, il a bien précisé que s'il y avait un nouveau composant avec de nouveaux indicateurs, il devrait rajouter des champs à la table. Pour moi, c'est pas une solution pérenne dans le temps et clairement une mauvaise modélisation (on perd la relation 1 type de composant possède 1 ou plusieurs indicateurs).  
 
Certes, la solution 3 est un peu plus complexe à mettre en oeuvre, mais tellement plus pérenne et élégante (répond tout à fait à l'énoncé de son pb)!
 
Pour info, Magento (soft de e-commerce en GPL) utilise la solution 3 pour définir les attributs associés aux produits à vendre. Mantis aussi pour les champs personnalisés liés aux fiches de bug. Et perso, j'ai fait pareil pour mon soft de gestion de conf Icare et pour Astres, mon soft de help-desk (pour les champs personnalisés associés aux tickets d'incidents, fortement inspiré de Mantis justement).

À nouveau : ça dépend, on ne peut pas le dire "comme ça". ça dépend de son utilisation plus qu'autre chose.
 
Je te conseille de jeter un oeil au très bon livre de Fowler Patterns of Enterprise Application Architecture. Dans la 2ème partie du livre il explique les différents patterns, dont le Single Table Inheritance et montre pourquoi dans certains cas c'est une bonne idée .
 
En ce qui me concerne j'aurais tendance à dire à da_s_monk:
- Si tu sais pour sûr (pas si tu penses, ni si tu espères ou crains, ...) que d'ici 1 an tu devras changer les colonnes de ta table, vas-y avec la solution 3. Elle sera un peu plus lente mais ça te simplifiera les modifications des colonnes.
- Sinon (donc si tu te dis "un jour sans doutes je changerai les colonnes, mais pour le moment je ne sais pas exactement quand ni comment), vas-y avec la solution 2. Elle est plus rapide à l'execution et suffisamment flexible pour te permettre quand même de modifier ton schémas plus tard.

J'avais acheté y'a qq années ce bouquin pour les design patterns : http://www.amazon.fr/Design-patter [...] 2841773507
 
Mais j'ai l'impression que les patterns dont ton bouquin parle sont de plus haut niveau. Ca m'a l'air pas mal, merci
 
Pour la modélisation d'un BD, je suis en général un puriste de la forme 3NF (même si je sais que les DBA ne l'apprécient pas pour des raisons de perfs ), d'où pourquoi ma nette préférence pour al solution 3...

Merci à tous.
effectivement, le nombre de colonnes est susceptible de changer plusieurs fois dans l'année au fur et a mesure que je rajoute des composants dans ma chaîne.
 
Mon principale problème avec la solution 3 est de savoir comment organiser mes requetes pour sortir des résultats "en ligne" comme je le ferai si je n'avais qu'une seule table.
Mais je pense pouvoir me débrouiller avec les exemples d'outils que vous m'avez fourni.
 
Par contre connaitriez vous le nom de ce type de base? c'est pour faciliter mes futures recherches.
 
Merci

entités-attributs éventuellement comme nom. Mais c'est une bête base de données. Je ne crois aps qu'on s'amuse à donner un nom pour chaque modélisation
Comme dit précédemment : regardes Magento, Mantis, Icare, Astres (partie tables "CustomFields" ).
la partie "présentation" n'est pas du ressort du SGBD mais de la couche présentation (ihm), cf design pattern "MVC". Icare et magento sont architecturés comme ça (mais magento, si c'est mieux fait, c'est aussi beaucoup plus complexe)...

C'est une base de donnée relationelle
 
Tu peux aussi ajouter une 4eme table avec les relations entre composant et indicateur, comme ca dans ta table de valeur tu n'as qu'un seul champ comme ID et pas deux (ce qui pourrais te faire gagner pas mal d'espace au final).
 
La solution 2 est un exemple typique de design a eviter comme la peste.
 
C'est toujours plus facil de faire un design de départ plus compliqué (ou plus poussé) que de récuperer un design simple et le transformer par apres (la ca tourne souvent au cauchemard).

J'abonde dans le sens d'Oliii...