Base de données embarquée ou fichiers XML ?

Bonjour à tous,

Je vais développer une appli qui devra gérer des films.
Chaque film aura une fiche avec des infos comme synopsis, réalisateur, année, genre, titre, affiche, acteurs ....

Ma question est la suivante : pour un projet de ce type, vaut-il mieux passer par des fichiers XML avec une structure bien définie ou une BD embarquée ?

Je me suis renseigné du côté de SQL Server CE et ce produit à l'air très intéressant : intégration dans VS, Entity Framework, Foreign Key, léger ...
Je pose cette question pour peser le pour et le contre de chaque solution.

Qu'en pensez-vous ?


Guillaume

Si le nombre de films reste relativement petit, un fichier XML peut faire l'affaire. Sinon une base de données est plus adaptée, notamment parce que ça permet d'exécuter efficacement des requêtes complexes (pour la recherche par exemple)

Citation:

---

Envoyé par tomlev

Si le nombre de films reste relativement petit, un fichier XML peut faire l'affaire.

---

Ca peut faire l'affaire c'est sur, mais cela n'apporte même pas de bénéfice en terme de lignes de codes et temps de développement.

Donc, à quoi bon ?

Citation:

---

Envoyé par Bluedeep

Ca peut faire l'affaire c'est sur, mais cela n'apporte même pas de bénéfice en terme de lignes de codes et temps de développement.

---

Ca dépend de l'approche utilisée... Si je devais faire ça avec un fichier XML, j'utiliserais la sérialisation XML, et ce serait vraiment pas lourd en lignes de code...

Avec des requêtes LinqToXml le temps de développement et ligne de code aussi ne serait pas très lourd puis l'intêret avec xml (comme base de données) c'est qu'il n'y a pas d'installation et des paramètres de configuration à régler comme cela doit se faire avec un SGBDR

Quel rapport avec l'embarqué ? Tu dois embarquer la base de données dans du matériel avec un window CE ?

Attention avec Entity Framework...

le connecteur pour SQL Server CE 3.5SP1 fourni les providers pour EF... pour dotnet 3.5SP1...
EFv1 donc...

Certes c'est déjà bien... mais attention quand même à bien regarder la doc de dotnet 3.5 si tu veux développer avec EF pour un serveur SQL Server CE.

nul part même sur la msdn il n'est fait mention d'une possible évolution ou future compatibilité avec EF4.
personnellement j'aurais tendance à en douter, car tout ce qui est CE ne semble plus la priorité de microsoft.

Citation:

---

Envoyé par cinemania

nul part même sur la msdn il n'est fait mention d'une possible évolution ou future compatibilité avec EF4.

---

Si si, c'est bien compatible, je l'utilise dans un projet perso avec EF4 et je n'ai pas remarqué de problèmes particuliers

En plus SQL CE 4.0 (actuellement en CTP) apporte pas mal d'améliorations, notamment pour l'utilisation avec EF, par exemple le support des colonnes générées par la base (identité etc), ce qui n'était pas le cas en 3.5. Et le provider ADO.NET implémente bien DbConnection.GetSchema (en 3.5 ce n'était pas supporté), ce qui peut être bien pratique dans certains cas.

http://blogs.msdn.com/b/sqlservercom...microsoft.aspx

Citation:

---

Envoyé par hegros

Avec des requêtes LinqToXml le temps de développement et ligne de code aussi ne serait pas très lourd puis l'intêret avec xml (comme base de données) c'est qu'il n'y a pas d'installation et des paramètres de configuration à régler comme cela doit se faire avec un SGBDR

---

La comparaison était vs une base de données embarquées (style Sql Server CE ou Sqlite) , pas vs un SGBDR; donc, par définition pas de notion de paramètres de configuration.

Citation:

---

Quel rapport avec l'embarqué ? Tu dois embarquer la base de données dans du matériel avec un window CE ?

---

Quand on parle de base de donnée embarquée, c'est vrai que c'est un abus de langage car cela inclut aussi une base "embarquée in-process dans l'application" par opposition à une base gérée par un SGBD.

Une base embarquée peut être une "vrai" base embarquée (Sqlite, Sql Server CE) ou tout simplement un pattern technique matérialisant uen base embarquée (exemple : un DataSet sérializé en Xml).

Citation:

---

Envoyé par cinemania

Attention avec Entity Framework...

le connecteur pour SQL Server CE 3.5SP1 fourni les providers pour EF... pour dotnet 3.5SP1...
EFv1 donc...

---

SQL Server CE 3.5SP2 est disponible depuis mai dernier.

C'est vrai que je suis tenté par Sql Server car je n'ai jamais touché à EF. Ca serait l'occasion d'apprendre.

Après, avec des outils comme Xsd2Code, la gestion par le XML est intéressante aussi.

Citation:

---

c'est qu'il n'y a pas d'installation et des paramètres de configuration à régler comme cela doit se faire avec un SGBDR

---

Sans dire de bêtises, mais avec CE, aucune installation n'est nécessaire.

tomlev, tu as de bonnes ressources pour SQL Server CE 4 avec EF 4 ?

Au final, au vu des différents avis, je pense me tourner vers une BD, qui founit, à mon avis, plus d'outils. De plus, pour les requêtes et les recherches ca sera plus pratique (du moins je pense).

Citation:

---

Envoyé par tomlev

Ca dépend de l'approche utilisée... Si je devais faire ça avec un fichier XML, j'utiliserais la sérialisation XML, et ce serait vraiment pas lourd en lignes de code...

---

Tout à fait; mais une approche SQL CE necessite également très peu de lignes de codes.

Citation:

---

Envoyé par Bluedeep

La comparaison était vs une base de données embarquées (style Sql Server CE ou Sqlite) , pas vs un SGBDR; donc, par définition pas de notion de paramètres de configuration.

---

Sql Server CE c'est quand même un SGBD il y a une petite installation (ce que j'appelle configuration) à faire ce n'est pas un fichier plat non plus.

Citation:

---

Envoyé par CARNIBAL

Sans dire de bêtises, mais avec CE, aucune installation n'est nécessaire.

---

SI il y a une petite installation quand même la base ne va pas apparaître par magie comme ça.

Oui un clic-droit sur le projet Visual Studio puis "Add Local Database".

Après c'est certains qu'il fut modéliser la base mais il faut aussi coder la serialisation XML et les structures des fichiers.

Mais comparé à l'installation puis la configuration de SQL Server, ce n'est rien.