• [^] # Re: explosion du trokilometre

    Posté par . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 2.

    Pour ce qui est d'UML, l'usage est plutot d'utiliser un stockage objet quand on modélise en objet (meme si ce stockage n'est qu'une couche de sérialisation par dessus un SGBDR). D'experience on rencontre d'ailleurs souvent des boucles avec des conditions complexes parcourant des listes d'objets pour faire des operations de reporting qui seraient triviales en attaquant directement la couche relationnelle.
    Ma conclusion : vive l'hybridation.

    Quand j'ai dis, malencontreusement "de l'odre de la dizaine", je pensais en fait "se compte en dizaines" comparé à la dizaine de milliers de tables d'un SAP.
    Par contre j'ai évoqué une compta et le problème que tu poses est celui d'un ERP ( gestion de stocks, de RH, des caisses ...). Je peux t'assurer que ce genre de fonction ne sont pas dans un soft de compta de base (elles font l'objet de fort couteux modules d'extension).
    Bref, comme je n'ai pas 3 mois devant moi et non plus qu'une connaissance correcte de la grande distrib je ne m'attaquerai pas à ton exemple.
    Mais si tu te referes à ma remarque plus haut tu noteras que je postule que justement la complexité est inhérente à ce genre de problème qui croise une multitude de facteurs et pas à leur representation relationnelle.

    Par contre je serai curieux (réellement, sans volonté polémique) de savoir comment ce genre de problème se résout en le modélisant par des graphes et quels outils tu peux utiliser pour passer du modèle à l'implémentation. Si c'est possible ca m'intéresse grandement.

    Si je ne m'abuse LDAP, XML sont des modéles d'arbres, pas de graphes(non dégénérés) ou justement on introduit des ID un peut artificiels pour representer les relations transversales.

    Dans les bases XMLnatives il y'a aussi Tamino de Software AG qui prétend à devenir pour le XML ce qu'Oracle est au relationnel.

    Pour les graphes ?