le but du modele relationnel est de synthetiser par groupe des relations fortes et en extraire des relations deduites par simple operations ensemblistes sur les relations.
quand on prend Merise dans sa definition, il ne correspond pas à l'application de Merise sur du modele relationnel. A cause du probleme des relations many/many . ce qui necessite l'introduction de tables pivot.
dans le cadre d'une application de gestion d'entreprise, nous avons :
- un arbre absolu nommé plan comptable
- un arbre ajourné nommé flux comptable
- un graphe des operations ajournées nommé "operations"
- un graphe de modeles d'operations
sachant que ces graphes et arbres se superposent mutuellement.
donc je te laisse faire un rapide compte du nombre de tables en relationnel.
si tu rajoute en plus du modele de comptabilité au bilan, une comptabilité analytique. tu as une explosion du nombre de tables.
Ajoute maintenant, que toute operation dans une entreprise represente un flux comptable et donc dois etre ajourné, que les ecritures ( qui sont des transactions ) dans une table d'un SGBDR SQL sont couteuses, tu comprendras qu'il faille necessairement des tables de sotckage qui sont agregé et agrégé et agrégé pour chacun des flux. avec le probleme de l'integrite referentiel au commit, cela empire.
maintenant, je rajoute une info, sur un systeme, comptable le rapport lecture/ecriture est tres proche du 1:1 et limite Write Only pour les tres gros systemes ( tracage du paquet de nouille dans un carrefour ).
pour en revenir a SQLite, je n'ai rien contre. si un jour je dois l'utiliser, je l'utiliserai sans etat d'ame. je ne suis pas un idealiste integriste, je suis aussi pragmatique.
[^] # Re: explosion du trokilometre
Posté par Mouns . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 2.
quand on prend Merise dans sa definition, il ne correspond pas à l'application de Merise sur du modele relationnel. A cause du probleme des relations many/many . ce qui necessite l'introduction de tables pivot.
dans le cadre d'une application de gestion d'entreprise, nous avons :
- un arbre absolu nommé plan comptable
- un arbre ajourné nommé flux comptable
- un graphe des operations ajournées nommé "operations"
- un graphe de modeles d'operations
sachant que ces graphes et arbres se superposent mutuellement.
donc je te laisse faire un rapide compte du nombre de tables en relationnel.
si tu rajoute en plus du modele de comptabilité au bilan, une comptabilité analytique. tu as une explosion du nombre de tables.
Ajoute maintenant, que toute operation dans une entreprise represente un flux comptable et donc dois etre ajourné, que les ecritures ( qui sont des transactions ) dans une table d'un SGBDR SQL sont couteuses, tu comprendras qu'il faille necessairement des tables de sotckage qui sont agregé et agrégé et agrégé pour chacun des flux. avec le probleme de l'integrite referentiel au commit, cela empire.
maintenant, je rajoute une info, sur un systeme, comptable le rapport lecture/ecriture est tres proche du 1:1 et limite Write Only pour les tres gros systemes ( tracage du paquet de nouille dans un carrefour ).
pour en revenir a SQLite, je n'ai rien contre. si un jour je dois l'utiliser, je l'utiliserai sans etat d'ame. je ne suis pas un idealiste integriste, je suis aussi pragmatique.