Citation:
....
Aujourd'hui, j'ai un oeil plus critique envers cet ERP, sa philosophie et son modèle des données. Et je le dit clairement, "c'est modélisé comme de la merde" (j'assume mes propos).
C'est le cas hélas de bien des ERP car les chef de projet de c genre d'engins sont plus à l'aise dans le code client que dans la base...
Citation:
Cependant, je ne lui enlève pas sa fabuleuse souplesse, car autant d'un côté il est modélisé n'importe comment, autant je suis convaincu que ce n'est pas le concept de l'outils qui n'est pas adapté aux SGBDR, mais les SGBDR qui ne sont pas adaptés à sa conception.
Car normaliser le modèle de cet outil, c'est aussi le brider complètement sur bien des aspects.
Non, je ne peut pas être d'accord.
Citation:
Un exemple simple.
Actuellement 3 tables avec (entre autres) les champs suivants :
MEV (codsoc, codent, segment, codsoc_phy)
EVE (codsoc, typeve, numeve, typtie, sigtie)
TIE (codsoc, typtie, sigtie, nomtie)
La table "EVE" sert à stocker des événement, qui peuvent aussi bien être :
- des devis
- des commandes
- des livraisons
- des factures
- des inventaires
- des poses de prothèses
- des ordonnances
- des publications de journal officiel
- le planning des cours d'un étudiant
- j'en passe des meilleures
La clé est "codsoc, typeve, numeve".
CODSOC indique la société à laquelle appartient l'événement (centrale d'achat, dépôt, magasin, hôpital, etc.)
TYPEVE indique le type d'événement (devis, commande, etc.)
NUMEVE indique le numéro d'événement
TYPTIE indique le type de tiers rattaché à mon événement (un utilisateur, un client, un fournisseur, un dépôt, un médecin, un patient, un magasinier,un vendeur, etc.)
SIGTIE indique le sigle du tiers en question.
Et dans la table TIE, on retrouve CODSOC, TYPTIE et SIGTIE.
Grace à ça, on peut savoir quel tiers est rattaché à tel événement.
MEV, quant à elle, permet de dire "bon, quand je suis dans la société 'X', pour la table 'Y' et le type d'élément 'Z', je dois aller lire en réalité dans la société 'A'".
Par exemple, je suis dans la société (10) "Dépôt de Paris", et je veux consulter les livraisons que je dois honorer.
Les livraisons ne sont pas créés au dépôt, mais au service commercial qui est dans une autre société (5).
Accessoirement, afin de pouvoir faire des négiciations au niveau national avec mes clients, ces derniers sont tous gérés dans la société hodling (1).
Alors y'a moyen de faire ça de façon normalisée.
Mais accrochez-vous pour les requêtes ensuite, surtout si elles doivent marcher chez un client qui a une organisation parfairement différente.
Ici, ça coule de source, pour chaque table lue, on va rechercher dans MEV la valeur du CODSOC à interroger : c'est "automatique", simple et parfaitement fonctionnel.
Par contre, en effet, y'a pas une seule clé étrangère,car on ne sais pas faire une clé étrangère qui pointe sur plusieurs tables à la fois.
Vous venez de prouver ce que je dis : comme on ne sait pas faire d'héritage, alors on bricole. Et donc pas de contraintes Foreign Key... mais savez-vous au moins que les FK dans les bons SGBDR (je parle pas de MerdeSQL...) permettant d'optimiser les requêtes notamment en abandonnant des jointures inutiles ?
Citation:
Jeu de données :
MEV (10, 'TIE', 'CLI', 1)
MEV (10, 'EVE', 'LIV', 5)
TIE (1, 'CLI', 'TOTO', 'Monsieur Toto')
EVE (5, 'LIV', 1, 'CLI', 'TOTO')
Et là, la magie du modèle des données pourri opère :
Code:
1 2 3 4 5 6 7
|
select eve.numeve, tie.nomtie
from mev meveve
inner join mev mevtie on mevtie.codsoc = meveve.codsoc and mevtie.codent = 'TIE' and mevtie.segment = eve.typtie
inner join eve on eve.codsoc = meveve.codsoc_phy and eve.typeve = meveve.segment
inner join tie on tie.codsoc = mevtie.codsoc_phy and tie.typtie = mevtie.segment and tie.sigtie = eve.sigtie
where meveve.codsoc = 10 and meveve.codent = 'EVE' and meveve.segment = 'LIV' |
Quel que soit le client chez qui cette requête sera utilisée, on n'aura que le paramètre "codsoc = 10" à remplacer par la société dans laquelle est connecté l'utilisateur, et "meveve.segment = 'LIV'" par le type d'événement qu'on essaie de consulter.
Dans la logique d'un ERP, ça peut justifier l'abandon de la puissance du SGBDR au profit d'une maintenabilité accrue.
Ça n'en reste pas moins pourrissime d'un point de vue modélisation dans l'optique d'une mise en place dans un SGBDR.
Et surtout des performances en volume...