Bonjour,
Je suis en train de réfléchir au modèle de données pour une application que je dois développer.
J'hésite entre 2 solutions et je ne sais pas quelle est la meilleure:
Mon entité principale est un projet, pour définir un projet j'ai besoin d'informations qui seront stockées dans X tables différentes.
Les 2 possibilités sont:
- En plus des clés nécessaires dans chaque table, je rajoute une clé pour l'identifiant du projet. J'aurais donc X tables (environ 7 ou 8 ) qui grossissent à chaque rajout de projet
- Je crée X tables pour chaque projet avec comme nom : "MA_TABLE_ID_PROJET". Mes tables auront donc une taille limitée par contre si j'ai 50 projets j'aurais 50 * X tables dans ma base de données.
Au niveau programmation, la seconde solution est plus simple à mettre en oeuvre (comme ca je peux créer facilement un projet à partir des données d'un autre projet, il me suffit de recopier les données de tables en tables et je n'ai pas de problèmes de clés) mais je ne sais pas si c'est très "propre" de multiplier ainsi les tables.
Qu'en pensez vous ?
Merci.
la communauté d'entraide francophone dédiée au PHP
Conception d'un modèle de données
Oui chacune des X tables correspond à un type d'élément du projet + des tables de laisons.La première, car créer X tables par projet, c'est lourd et en outre ce n'est normalisé, tu risques de rencontrer des problêmes par après.
J'imagine que sur les X tables nécessaires pour stocker un projet, elles ont toutes des structures différentes ??
Si ça peut t'aiguiller sur la méthode à adopter, je dirais que pour concevoir un modèle conceptuel, il te faut commencer par créer un dictionnaire de données: tous les noms des éléments que tu auras à traiter. Par la suite, sépare ces éléments en entités et attributs, ce qui signifie en clair que certains mot deviendront des tables, d'autres des colonnes dans ces tables.
Enfin, créer une table par projet est insensé: à terme, tu risque de ne plus t'y retrouver dans toutes les tables: par contre, chaque projet peut être clairement identifié et comporte un certain nombre d'éléments propres et d'éléments variables qu'on retrouvera dans d'autres tables liées par des relations. Par exemple, tel élément appartiendra 1 et 1 seule fois à un projet et le projet comportera cet élément 0 ou n fois : ce sont les cardinalités que tu vas définir. Mais dans l'ensemble, d'un projet à l'autre, tu retrouveras les mêmes caractéristiques, donc pourquoi faire des doublons en créant autant de tables qu'il y a de projets?
Enfin, créer une table par projet est insensé: à terme, tu risque de ne plus t'y retrouver dans toutes les tables: par contre, chaque projet peut être clairement identifié et comporte un certain nombre d'éléments propres et d'éléments variables qu'on retrouvera dans d'autres tables liées par des relations. Par exemple, tel élément appartiendra 1 et 1 seule fois à un projet et le projet comportera cet élément 0 ou n fois : ce sont les cardinalités que tu vas définir. Mais dans l'ensemble, d'un projet à l'autre, tu retrouveras les mêmes caractéristiques, donc pourquoi faire des doublons en créant autant de tables qu'il y a de projets?
Codez en pensant que celui qui maintiendra votre code est un psychopathe qui connait votre adresse 
En fait, les entités sont déjà définies, j'ai déjà quasiment fini de déterminer la structure de mes X tables (hormis le fait de savoir si je rajoute la clé du projet ou si je crée des tables propres à chaque projet).Si ça peut t'aiguiller sur la méthode à adopter, je dirais que pour concevoir un modèle conceptuel, il te faut commencer par créer un dictionnaire de données: tous les noms des éléments que tu auras à traiter. Par la suite, sépare ces éléments en entités et attributs, ce qui signifie en clair que certains mot deviendront des tables, d'autres des colonnes dans ces tables.
Enfin, créer une table par projet est insensé: à terme, tu risque de ne plus t'y retrouver dans toutes les tables: par contre, chaque projet peut être clairement identifié et comporte un certain nombre d'éléments propres et d'éléments variables qu'on retrouvera dans d'autres tables liées par des relations. Par exemple, tel élément appartiendra 1 et 1 seule fois à un projet et le projet comportera cet élément 0 ou n fois : ce sont les cardinalités que tu vas définir. Mais dans l'ensemble, d'un projet à l'autre, tu retrouveras les mêmes caractéristiques, donc pourquoi faire des doublons en créant autant de tables qu'il y a de projets?
Le problème c'est que je risque de me retrouver avec des tables très grosses, et j'avais aussi peur que cela crée des problèmes au niveau du fonctionnement de mon appli, je ne sais pas quelle est la limite de MySQL (en terme de qualité de fonctionnement par rapport au nombre d'enregistrements d'une table)
Par exemple un seul projet peut engendrer dans une table la création d'environ 200 000 enregistrements, donc si j'ai 50 projets...
Si je comte bien, ça peut donc arriver à 10 millions d'enregistrement: que ce soit sur un ou plusieurs tables, ce sera la même quantité à stocker;
Par contre, au niveau de la rapidité des requêtes, il faudra très soigneusement choisir les index.
Il faudrait fouiller sur le site de MySQL pour trouver les limites, je ne les pas trouvé. Quoi qu'il en soit, pour une base de cette taille, la conception doit être particulièrement bien définie, le droit à l'erreur n'est plus verment permis.
À ce niveau là, je ne me sens pas tout à fait assez compétent pour te conseiller davantage.
Par contre, au niveau de la rapidité des requêtes, il faudra très soigneusement choisir les index.
Il faudrait fouiller sur le site de MySQL pour trouver les limites, je ne les pas trouvé. Quoi qu'il en soit, pour une base de cette taille, la conception doit être particulièrement bien définie, le droit à l'erreur n'est plus verment permis.
À ce niveau là, je ne me sens pas tout à fait assez compétent pour te conseiller davantage.
Codez en pensant que celui qui maintiendra votre code est un psychopathe qui connait votre adresse
En tous cas merci pour les infos.Si je comte bien, ça peut donc arriver à 10 millions d'enregistrement: que ce soit sur un ou plusieurs tables, ce sera la même quantité à stocker;
Par contre, au niveau de la rapidité des requêtes, il faudra très soigneusement choisir les index.
Il faudrait fouiller sur le site de MySQL pour trouver les limites, je ne les pas trouvé. Quoi qu'il en soit, pour une base de cette taille, la conception doit être particulièrement bien définie, le droit à l'erreur n'est plus verment permis.
À ce niveau là, je ne me sens pas tout à fait assez compétent pour te conseiller davantage.
Il faut prendre en compte l'aspect hardware également, sur quel type de serveur physique cette base de donnée va elle être ??
(Si c'est sur un hébergement web gratuit
)
Mais comme l'a dit Cyrano, il faut pas se louper dans la structure :
Que ça soit vraiment normalisé complêtement, et optimiser au niveau des index etc...
ps : 200.000 enregistrements/projets, c'est quoi comme projets, si c'est pas indiscret ?? 8) 8)
(Si c'est sur un hébergement web gratuit
)Mais comme l'a dit Cyrano, il faut pas se louper dans la structure :
Que ça soit vraiment normalisé complêtement, et optimiser au niveau des index etc...
ps : 200.000 enregistrements/projets, c'est quoi comme projets, si c'est pas indiscret ?? 8) 8)
Salut,
juste quelques chiffres sur MySQL:
Sabre(http://www.sabre.com/) à, par exemple, construit un data warehouse de plus de 4 To
http://fr.news.yahoo.com/050426/44/4dtnq.html
Sinon la plus grosse base dont j'ai entendu parlé fais 7To
(un boite de telecom en Finland)
Donc a prioris 10 millions d'enregistrement, ça passera, a condition que ton modele soit optimisé
++
Daz
juste quelques chiffres sur MySQL:
Sabre(http://www.sabre.com/) à, par exemple, construit un data warehouse de plus de 4 To
http://fr.news.yahoo.com/050426/44/4dtnq.html
Sinon la plus grosse base dont j'ai entendu parlé fais 7To
(un boite de telecom en Finland)Donc a prioris 10 millions d'enregistrement, ça passera, a condition que ton modele soit optimisé
++
Daz
au niveau des X tables autour du projet, la modelisation par meta données est interessante pour minimiser le dev d'interfaces.
link: http://sqlpro.developpez.com/cours/mode ... tadonnees/
Par contre coté volume de données, je ne sais pas ce que ça donne sur des millions de lignes...
A+
Pascal
link: http://sqlpro.developpez.com/cours/mode ... tadonnees/
Par contre coté volume de données, je ne sais pas ce que ça donne sur des millions de lignes...
A+
Pascal
Salut,
encore qq chiffres
L'éditeur américain O'Reilly a ainsi bâti un datawarehouse de 10 Go de données à partir de Perl (pour la partie ETL), MySQL (pour le stockage) et de Jasper et Excel pour les analyses et le reporting. Il estime son économie à
75 % par rapport à des outils propriétaires traditionnels.
Les gains de Sabre R&D sont du même ordre. Pour analyser environ 100 millions de transactions par jour, le système de réservation a bâti un datawarehouse de 2,6 To de données. L'ETL GoldenGate alimente une base MySQL et JasperReports fournit les rapports tandis que les analyses sont réalisées avec les outils de Cognos et directement en SQL (MySQL Browser) par les utilisateurs finaux.
http://www.indexel.net/1_6_4086__3_/15/ ... atures.htm
++
Daz
encore qq chiffres
L'éditeur américain O'Reilly a ainsi bâti un datawarehouse de 10 Go de données à partir de Perl (pour la partie ETL), MySQL (pour le stockage) et de Jasper et Excel pour les analyses et le reporting. Il estime son économie à
75 % par rapport à des outils propriétaires traditionnels.
Les gains de Sabre R&D sont du même ordre. Pour analyser environ 100 millions de transactions par jour, le système de réservation a bâti un datawarehouse de 2,6 To de données. L'ETL GoldenGate alimente une base MySQL et JasperReports fournit les rapports tandis que les analyses sont réalisées avec les outils de Cognos et directement en SQL (MySQL Browser) par les utilisateurs finaux.
http://www.indexel.net/1_6_4086__3_/15/ ... atures.htm
++
Daz
