Format d'un fichier de sauvegarde

Bonjour à tous,
je compte développer une petit appli de gestion de compte (pour un usage perso - ce que je trouve sur internet, gratuit ou payant ne me convient pas).

Je me pose la question du format des fichiers de sauvegarde.

Je pensais tout écrire (Propriétés des comptes, opération etc) dans un fichier XML (un fichier tous les 6 mois par exemple, ce qui limite la taille du fichier pour la lecture)

Je pense que la mise en place d'une BDD est un peu lourde pour ce genre de projet.

Qu'en pensez vous ?

Qu'il est dangereux d'utiliser du XML pour stocker des données de longueur vouée à augmenter.

Tu devrais plutot regarder à mettre en place une base de données légère comme sqlite (tutorial ici )

Ce n'est pas contraignant : Ta base de données ne nécessite pas de serveur et est stockée dans un seul fichier.

Je vais regarder ça merci =)

PS: je suis aussi ouvert à d'autres suggestions.

Tu peux aussi utiliser une base SQL Server Compact mais elle possède un poil moins de fonctionnalités qu'une base SQLite.
Cela dit, c'est très bien intégré dans Visual Studio, et même installé par défaut avec une version non Express de Visual Studio.

Bonjour,
je relance le sujet car j'ai bien avancé dans mon projet mais j'ai toujours un doute sur le format des fichiers de sauvegarde.

J'ai développé mon appli avec une BDD SQL Server Express (et Entity Framework).
En mode développement ça marche correctement, mais j'ai l'impression qu'au sujet de l'installation ça n'est pas simple. Si je veux donner mon appli à quelqu'un, la configuration de la BDD ne risque pas d'être lourde ? (installer sql se, configurer l'accès à la base etc). Je ne me suis pas beaucoup penché sur le déploiement de projet utilisant une bdd mais mes premiers essais ne sont pas concluant.

Du coup j'en reviens au format XML. Qu'y a-t-il de dangeureux à l'utiliser pour la sauvegarde ?
La quantité de données n'est pas si importante que ça :
Si on compte environ 50 opérations par mois x 12 ça ne représente que 600 ligne en 1 ans d'utilisation. Avec Linq le traitement est à peine plus compliqué qu'avec Entity Framework et j'ai plus l'impression de maîtriser le contenu de mes fichiers qu'avec un fichier .sdf

Citation:

---

Envoyé par flzox

Si on compte environ 50 opérations par mois x 12 ça ne représente que 600 ligne en 1 ans d'utilisation. Avec Linq le traitement est à peine plus compliqué qu'avec Entity Framework et j'ai plus l'impression de maîtriser le contenu de mes fichiers qu'avec un fichier .sdf

---

Quel interêt d'avoir accès au contenu du fichier ?

Citation:

---

Envoyé par Bluedeep

Quel interêt d'avoir accès au contenu du fichier ?

---

Il est pas énorme en effet. Disons qu'il est éditable en mode texte en cas de problème, si un fichier sdf est foireux ou vérolé c'est plus compliqué.

Enfin ma question porte surtout sur :
- Pourquoi n'est-il pas recommandé d'utiliser xml pour mon projet ?
- Utiliser une BDD n'est-ce pas sortir l'artillerie lourde pour rien (dans mon cas), et question déploiement est-ce pratique ?

Pense à tes utilisateurs qui voudrons centraliser les données d'une flotte de PC ?

Imagine par exemple une entreprise qui choisi d'utiliser ton logiciel pour permettre à ses employés de saisir et suivre leurs notes de frais.
=> Toutes les fins de mois, la RH demande aux employés de faire une synchronisation de leur base sur un serveur central, afin d'intréger les informations ensuite dans le logiciel de paie.

Si tu utilises SQL Server Express (ou Compact Edition, qui me semble plus judicieux, surtout si tu te dis qu'un jour ton appli pourrait être utilisée aussi sur SmartPhone), ça va se faire pour ainsi dire tout seul.

Avec un fichier XML, la synchro sera 100% manuelle et des développements complémentaires seront nécessaires pour consolider les données.

Bon, c'est un exemple dans le vent hein...