> Heu, aucun des concepts que tu cites ne sont inclus dans la facture, ce ne sont que des associations...
Pardon? Le but de la modélisation c'est justement de distinguer une facture papier (sur laquelle apparaissent les concepts que j'ai cités) des objets qui en résulteront. Si votre méthode de modélisation appelle ces objets des 'associations' il serait peut-être temps de passer à UML. ;-)
> Le seul moyen que je vois pour avoir 30000 tables c'est de faire de la fédération ou que la base soient vraiment très mal concue.
J'ignore de quoi il s'agit. Mais il existe bien des domaines (telecom par ex) où les SGBDR sont utilisés avec des bases absolument pas normalisées (et pour cause) et dont on ne peut pas dire qu'elles sont mal conçues. Le modèle n'est pas relationnel c'est tout. Concernant les ERP il faut avouer qu'un bon tiers de ces tables contiennent du code et/ou des IHM, etc... (cf ABAP)
> Mais en pratique tu trouves les tables clients, prospects, contacts....
C'est le principe de la spécialisation/généralisation. Rien ne vous permet de dire que la base est mal conçue sans connaitre le modèle conceptuel et les critères qui ont amenés à ce choix d'implémentation physique. Quand on commence à jouer avec des tables de plusieurs dizaines de millions d'enregistrement, on laisse de coté le dogmatisme et on apprend vite que la dénormalisation peut accélérer certains traitements d'un facteur 100 (c'est du vécu). Il faut toujours se méfier des jugements trop hâtifs.
[^] # Re: Outil graphique de gestion de base de données
Posté par Raoul Volfoni (site web personnel) . En réponse à la dépêche Outil graphique de gestion de base de données. Évalué à 1.
Pardon? Le but de la modélisation c'est justement de distinguer une facture papier (sur laquelle apparaissent les concepts que j'ai cités) des objets qui en résulteront. Si votre méthode de modélisation appelle ces objets des 'associations' il serait peut-être temps de passer à UML. ;-)
> Le seul moyen que je vois pour avoir 30000 tables c'est de faire de la fédération ou que la base soient vraiment très mal concue.
J'ignore de quoi il s'agit. Mais il existe bien des domaines (telecom par ex) où les SGBDR sont utilisés avec des bases absolument pas normalisées (et pour cause) et dont on ne peut pas dire qu'elles sont mal conçues. Le modèle n'est pas relationnel c'est tout. Concernant les ERP il faut avouer qu'un bon tiers de ces tables contiennent du code et/ou des IHM, etc... (cf ABAP)
> Mais en pratique tu trouves les tables clients, prospects, contacts....
C'est le principe de la spécialisation/généralisation. Rien ne vous permet de dire que la base est mal conçue sans connaitre le modèle conceptuel et les critères qui ont amenés à ce choix d'implémentation physique. Quand on commence à jouer avec des tables de plusieurs dizaines de millions d'enregistrement, on laisse de coté le dogmatisme et on apprend vite que la dénormalisation peut accélérer certains traitements d'un facteur 100 (c'est du vécu). Il faut toujours se méfier des jugements trop hâtifs.