Choix entre XML et une base de données relationnelle [Résolu]

[pbatty1]

Bonjour,
Je suis en train de me poser la question sur le choix entre l’utilisation d’une base données ou de XML.
Mon projet concerne la création de règles qui serviront dans la RH. Ces règles permettent de calculer les heures supp, les primes,… une règle est composée de condition, d’action. Une condition peut être simple ou complexe (groupement d’autres règles simple). La question que je me pose est il bénéfique d’utiliser XML dans le stockage de l’information ou une base de données relationnelle?
La recherche d’information dans un fichier XML est assez lente comparée à une base de données relationnelle. Mais l’imbrication de la condition (condition complexe) n’avantage t-il pas le fichier XML ?
Je sollicite votre expertise pour m’aider à faire le choix entre un fichier XML et une base de données. C’est surtout du coté de la performance qui est important.
Actuellement, je combine les deux outils c'est-à-dire, j’utilise une base de données relationnelle où je stocke mes informations sur les variables, les actions,les conditions, les règles sous format XML.
Je vous remercie à l’avance de votre aide

[Hephaistos007]

Je suis curieux de savoir quel schéma de BDD tu proposes pour stocker des règles. En fonction de ta réponse, on pourra sans doute te donner notre avis.

[SQLpro]

Vous pouvez parfaitement définir une structure arborescente dans votre modèle de données afin de représenter une règle qui en englobe d'autres. Pour cela vous pouvez utiliser des requêtes récursives ou bien le mode intervallaire de représentation des arborescences.
Sur ces deux éléments, consultez les papiers que j'ai écrit :
http://sqlpro.developpez.com/cours/s...te-recursives/
http://sqlpro.developpez.com/cours/arborescence/

A +

[michel.bosseaux]

A priori, je dirais que XML est à réserver à un fichier d'exportation, pour passer des données d'un programme à un autre, ou bien à des données qui ne doivent pas être (souvent) modifiées. Dans les deux cas, il ne faut pas non plus que le volume de données dans le fichier soit trop important.

Et pour les données dont la représentation est plus simple en XML, la solution de mettre du XML en DB n'est pas mauvaise, mais là non plus il ne faut pas en abuser. Il sera toujours plus efficace (même si p-e moins simple à mettre en place) d'avoir les champs en DB plutôt qu'un XML à décoder.

[GrandFather]

Bonjour,

pour la sérialisation de données hiérarchiques, j'aurais tendance à favoriser XML. Il y a tout un ensemble de technologies conçues pour permettre de requêter (XPath, XQuery), transformer (XSLT), valider (W3C XML Schema, Relax NG), manipuler (DOM) des données dans ce format, de manière plus simple qu'avec une base de données relationnelle. Si les performances sont un problème, il existe des bases de données natives XML (eXist, XIndice) offrant des possibilités d'indexation et de cache.

Mais ce n'est qu'une tendance, dans un projet complexe, comme cela semble être le cas ici, il y a bien d'autres paramètres à considérer.

Si le but est d'externaliser hors de l'application les règles métiers et de créer un moteur de règles, il y a peut-être une autre possibilité, mais qui n'a plus grand chose à voir avec les bases de données ; ce serait de modéliser les régles dans un langage de script pouvant être interprété par l'application principale, à l'instar de ce qui existe pour Java 6 et Javascript (il y a d'autres langages de script disponibles).

[pbatty1]

Une règle est composée d’une et une action et une et une condition
Règle(IDRègle, NomRegle, …, #IDAction,#IDCondition)
Une action est composée d’une et une variable
Action(IDAction,NomAction,…,#IDVariable)
Variable
Les données sur la variables peuvent être modifiées en table variable

<Variable IndexVariable="1" Type="F">
<UnitMeasure></UnitMeasure>
<CodeName>JOUR</CodeName>
<ListSource>
<List>Dimanche;Lundi;Mardi;Mercredi;Jeudi;Vendredi;Samedi;</List>
<TableName></TableName>
<CodeField></CodeField>
<DescField></DescField>
</ListSource>
<Meta>
<Name>Jour de la semaine</Name>
<Comment>
Kit
initialisation </Comment> <Category> Condition </Category> <CreatedBy> Herivola </CreatedBy>

Condition

<Condition IndexCondition="6" Type="M">
<IndexConditions>
<IdCond>1</IdCond>
<IdCond>2</IdCond>
</IndexConditions>
<BinaryOp>ET</BinaryOp>
<Meta>
<Name>Si heure par jour entre 8 et 10</Name>
<Comment></Comment>
<Category>Surtemps</Category>
<CreatedBy></CreatedBy>
<Date>2009-03-10 14:39:28</Date>
</Meta>
</Condition>

Une condition peut être simple ou multiple. Une condition multiple est une composition de condition simple. L’exemple ci-dessus est une condition multiple. Elle est composée de la condition simple 1 et 2. On ne sait jusqu’à quelle profondeur va l’imbrication.
J’ai regardé un peu les solutions qui vous avez proposé et il parait que SQL server n’est pas très performant dans les requêtes imbriquées. La solution avec une définition des parents et fils dans les conditions peuvent être une solution efficace, qu'est ce que vous en pensez? Le projet de générateur de règle tourne sur SQL Server donc ça limite les possibilités.

[Waldar]

Envoyé par pbatty1

il parait que SQL server n’est pas très performant dans les requêtes imbriquées

Il parait que XML c'est nul (quoi, cette allégation ne met pas fin au débat ?)

Soyons sérieux, et postez des sources si vous avancez ce genre d'argument, sinon à part mettre SQLPro en colère vous n'arriverez à rien !

A ma connaissance il n'y a aucun soucis avec SQL Server et les requêtes imbriquées, vous avez du confondre avec Access ou MySQL.

Pas de soucis avec les hierarchies non plus.

[pbatty1]

Je vous remercie pour vos reponses. En conclusion, il est tout a fait faisable de representer ce projet avec seulement l'aide d'une base données.