Salut,
 
J'ai envie d'ecrire un petite application sur mon temps libre (un ptit truc de nutrition pour voir ce que je consomme) et je me demande si c'est mieux de partir avec des fichiers (binaires, XML, ou autre) qui sauvegarderont mes donnees ou une base de donnee. Je pensais partir sur une base de donnee, car je n'ai (quasiment) aucune experience et que ca parait interessant, mais j'aimerai bien savoir comment trancher intelligement.
 
Sur le nombre de donnees qu'on va stoquer? ici je dirais dans la centaine.
 
Si j'ai differentes categories de donner, quand stoquer certaines en SQL et d'autres en fichier?
 
 
Merci pour tout eclaircissement.

Quelques pistes de réflexion :
 
Faisabilité : Il est possible de stocker des données soit dans des fichiers, soit dans une base de données.
 
Sécurité : La sauvegarde régulière de fichiers ou d'une base de données est possible. Les bases de données ont souvent une fonction de journalisation qui peut parfois permettre une récupération lors de coupures de courant. Il existe parfois une fonction de test de la cohérence d'une base de données, et une fonction de récupération, qui peuvent parfois s'avérer utiles en cas de problème disque. Pour éviter le piratage, il est souvent possible d'encrypter les données avec les deux systèmes.
 
Rapidité de développement : C'est peut-être plus rapide d'utiliser des ordre SQL plutôt que de développer ses propres routines de select, insert, update, delete. Avec les bases de données il existe aussi souvent des fonctions de gestion de dates assez pratiques.
 
Maintenabilité : C'est sans doute plus facile pour une personne ne connaissant pas le code, ou ne sans souvenant plus, de lire des ordres SQL plutôt que des fonctions maison d'accès aux données. Ajouter ou modifier une colonne est souvent assez simple à faire avec une base de données.
 
Rapidité d'exécution : L'accès aux données dans les fichiers est plus rapide, à condition toutefois d'avoir de bons index, et de nos jours les bases de données sont assez rapides.
 
Portabilité : Les fichiers sont universels, donc sont sensés être plus portables, mais de nos jours les bases peuvent souvent être portées d'un systèmes d'exploitation à l'autre. De plus, il existe des interfaces telles que ODBC ou JDBC qui permettent de ne pas se soucier de l'emplacement physique d'une base.
 
Encombrement : Les bases de données sont parfois plus grosses que les fichiers. Mais ce n'est pas toujours vrai, par exemple, parce que les bases de données offrent souvent le type varchar qui réduit l'encombrement, alors que le développeur utilisant les fichiers n'aura peut-être pas voulu s'ennuyer à gérer des tailles variables de chaînes de caractères.

Pour moi c'est surtout l'utilisation que tu vas en faire, avec une base de données, tu vas pouvoir torturer tes données dans tous les sens sans soucis ou sans aucun dev supplémentaire (filtre / moyenne / ordre de tri etc etc)

olivthill a bien résumé le problème.
 
un autre aspet, c'est si tu as des données liées d'un "fichier" à l'autre, les bases de données permettent de vérifier la cohérence.
 
par exemple, dans un soft de nutrition, impossible d'imposer un régime avec un ingrédient qui n'existe pas dans le fichier des ingrédients. via fichier, tu n'es trop sûr de rien, parceque même si tu le gères dans ton fichier, tu n'es pas à l'abri de la substitution d'un fichier par un autre (erreur de manip, patch, etc.)

Hmm.
 
Merci pour vos reponses, ce qui m'embete un peu dans celles-ci est qu'il n'y a pas vraiment de debat, on dirait que dans tous les cas la BDD est mieux alors qu'il y a surement des cas ou ce n'est pas interessant non?

bah ça dépend si tu veux un format de données ouvert et portable ou une zone de stockage hermétique manipulable uniquement par des primitives SQL.

Tu penses a des trucs type XML Taz?

bah ça dépend si t'as besoin de structure ou pas du tout. un fichier plat ça le faire. ou bien imaginons que tu fasses ton truc en langage ruby/machin/truc/toussa, tu peux juste carrément dumper tes structures de données et pas réfléchir du tout.

Ben y a pas de débat, car bon ca fait bien longtemps que ce débat est terminé et que y a pas photo entre fichier et base.
Au pire c'est juste les exports et flux qui se font par des fichiers, mais pour le reste on passe par les BD.
 
En gros on utilise plus les diligences, car on s'est aperçu que les trains c t quand même beaucoup mieux

@Taz: rah les fichiers binaires en Java (j'ai oublier le nom ) c'est sur que c'etait fort pratique.
 
@Sebastien: Ben ce que je ne comprend pas, c'est que s'il n'y a pas de debat, pourquoi une bonne partie des applications sauvegardent toujours leurs donnees dans des fichiers?
Tu voudrais dire qu'alors dans la plupart de ces cas, une BDD legere aurait ete mieux?

Tu penses à quel genre d'applications quand tu dis que de nombreuses applications sauvegardent leurs données en format fichier ?
 
En effet, il faut faire attention à un truc quand tu vois fleurir des fichier "*.dat" ou autres dans les répertoires des programmes : bien souvent, il s'agit de bases de données (propriétaires ou non) à base de fichier, comme dBase.
 
Le programme bénéficie donc d'un moteur de base de données pour gérer les données, sans devoir installer un service "serveur". Mais ça n'en reste pas moins une base de données : il ne se soucie pas de la façon dont sont stockées et lues les données dans le fichier.
 
C'est très important de garder ça en tête à partir du moment où niveau maintenance et évolutivité, gérer des fichiers plats, ça peut très rapidement devenir l'horreur (duplication d'algorythmes pour causes de structures différentes, refactorisation du code foireuses, etc. car on a tendance à ajouter des petites spécificités liées au données en plein milieu d'un traîtement plus général).

hormis les cas de configuration, ou la tu peux largement garder dans un simple fichier, les autres cas oui tout à fait, mais après y a des contraintes autre qui font qu'on est obligé d'utiliser des fichiers.
Les applications étant independantes tu peux pas demander à tes clients (je parle des particuliers) d'avoir une bdd opérationnelle et maintenue chez eux.

Mais dès que tu passes dans des applications interne professionnelles elles sont toutes avec BDD

On va dire qu'un éditeur ne peut pas se permettre de faire sa propre bdd dans ses softs et ne peux pas vendre un produit trop dépendant d'un autre (tjs pour les particuliers)
Mais n'empeche  pour bcp de softs ils ont un systeme de gestion des données en interne.
En gros ils chargent les fichiers dans un moteur interne, puis tout travaille en type BDD, puis à la fin ils sauvegardent dans un fichier plat.

C'est pas que tu vois un fichier que c'est pas une base derrière

La plupart de mes applications je pense que ca soit KDE, mplayer, etc.
Apres tu as un point interessant quand tu parles des .dat.
 
Sinon de memoire FFX3 est passe au SQL aussi pour les marque pages donc cela rejoindrait ce que vous dites.
 
Merci!

MagicBuzz a été bcp plus clair que moi je dirais sur ce coup

Non ton explication a ete tres bien aussi

Ecoute pas l'autre, le débat est tellement terminé que la majorité des données informatiques ne sont pas stockées dans des base de données mais dans des fichiers textes ou binaires. Comme je te disais, le format du stockage de données, c'est une histoire de portabilité, extensibilité, accessibilité, etc. Tu vas pas me dire que t'es pas content quand tu trouves un fichier et que tu peux l'ouvrir avec ton éditeur de texte ... ou même, t'es bien content de pouvoir cat/piper des trucs de temps en temps non ?
 
C'est pas fichier vs. SQL. SQL c'est un langage. Y a les fichiers textes, les fichiers binaires, les annuaires, les SGBDR, les SGBDO, les SGBDH, etc, etc.
Pour le texte,y a des modèles simples avec des fichiers plats, genre fichiers de fortune, fichier de traduction, etc.
 
Joue avec ce que tu veux, mais faudrait pas non plus systématiquement pondre du sqlite pour 2 clefs 3 valeurs.

Alors selon toi quand choisir un type de sauvegarde et quand choisir l'autre?
 
Portabilite bah c'est sur qu'un fichier texte est portable, sauf s'il est encode en utf16 et que tu passes sur un systeme uniquement iso-machin. Donc ca ne change pas tellement d'un SQLite qui est disponible sur pas mal d'architecture.
 
Apres c'est sur que personnelement, pouvoir changer la config de KDE a la main quand il plante, bah c'est un must sinon je ne vois pas trop comment je pourrais faire, donc les fichiers textes ca reste pratique a mes yeux. Peut etre juger la dessus? Aurai-je besoin d'editer ces informations manuellement par la suite?

en portabilité j'entends aussi que n'importe qui ou quoi peut manipuler ce format sans problème. En règle général on a pas toujours libxml2 ou le driver sql qui va bien sur le serveur de prod, etc.
 

"640K is more memory than anyone will ever need"
 
 
C'est quoi tes données d'ailleurs ?

1- Meme pas un truc type phpmyadmin ?
 
2- Je pose plus la question dans un cas general, mais dans le cas immediat des portions de nourriture en gros.
 
3- Donc pour toi, quand est-ce utile d'avoir une DB?

Mais y a pas de réponse générale justement.
Ta gestion de bouffe, tu vas y stocker quoi ? quantité ? type d'accès ? fréquence ? type de données ?

- quantite ouais
- j'aimerais avoir acces par une appli Qt et plus tard peut etre par le web
- frequence d'acces faible, c'est juste pour apprendre 2-3 trucs pour moi, donc pas besoin d'un truc super rapide, je dirais max une "requete" par 15 secondes.
- string et int a vue de nez.

vu le type de truc, le meilleur compromis me semble dbase quand même : pas d'application serveur, et c'est à base de fichiers. n'importe quel programme peut l'utiliser sous windows tel quel

lecture ? écriture ? mise à jour ?

Je ne tourne sous Windows qu'au travail
Ca c'est un projet personnel donc pas de Windows autour.
 

 
- acces en lecture plus souvent qu'en ecriture une fois que la base commence a etre rempli.
- peu de donnees seront mises a jour par la suite

bah si ça va tourner autour d'une liste, comme je t'ai dit: ça se dump facile dans un fichier, en textuel ou automatiquement, après t'as des trucs à la dbm clef->valeur. si t'as besoin de plus alors oui là tu as le sqlite si pour n'avoir qu'une table a 2 colonnes ...

plus 4 table a 3-5 colonnes

Taz tu reproche quoi à l'utilisation d'un système style SQLite ? D'accord tu peux pas éditer à coups de Emacs le fichier obtenu, mais au fond pourquoi aurais-tu besoin de le faire?
Je suis aussi d'accord que si tu veux passer ton programme sur un obscure système ne permettant pas de l'installer, t'es dans la merde alors qu'avec un fichier plat (style XML ou YAML) tu peux toujours te ré-implémenter à la main le système de lecture/écriture ... Mais je suis forcement persuadé que ça vaille la peine de te faire chier pour ça ... À la limite tu créera une lib de gestion de fichiers plats au cas où le besoin se faisait sentir

xml alors, en utilisant un langage de haut niveau qui sait sérialiser proprement des dataset en xml

Mais je reproche pas. Mais tu vois ce que tu décris, ça part vite en couille avec l'obligation de créer un dataloader exprès pour un machin aussi simple de recette de cuisines. Dans l'absolu, ça vaut souvent la peine d'y réfléchir 2 secondes avant de se lancer des formats de fichiers dur à backuper, à vérifier, etc pour des petites applications. Des trucs à la JSON c'est quand même pas mal. Mais faut pas non plus négliger le code que tu va cramer en select* machin, construire des objets, toussa, par rapport à un dbm.open { |db| db[key] += 45kg de lasagnes-frites }

@taz: C'est quoi ton dbm, ca a l'air pas mal aussi?
 
@MagicBuzz: genre XML + LibXML?
J'ai cela sur un projet au travail, j'ai peut etre mal compris le principe mais je ne trouve pas cela si rapide a ecrire comme code.

bah toutes les bdb, dbm, gdbm, hdb, etc y en a des tonnes sur le même principe. c'est assez standard comme format (pas mal de soft utilise ça genre postfix, etc), c'est simple et fastoche à utiliser. certains langages ont des trucs comme ça dans un format perso mais c'est le meme principe. Ca se présente comme un dico, et tous les objets que tu mets dedans, bah ils sont restaurés tels quels.

Ben ça dépends.
 
Essaie en C#, ça marche tout seul la sérialisation de dataset, et l'intérêt c'est que c'est relationnel et typé. Pas besoin de t'emmerder à gérer à la main la recherche d'éléments, les mises à jours dans le fichier ou autres.
Et quand t'as la structure à changer, t'as juste un XSD (généré automatiquement) à déployer... C'est quand même bien plus pratique que des fichiers plats où faut écrire un programme EXPRES pour changer la structure des fichiers...
 
Et en C#, du moment que tu veux binder des données dans un contrôle, t'es pour ainsi dire obligé de passer par un dataset, donc...

genre le pstore de ruby, le shelve de python, etc

 
Je me rappelle quand j'avais codé une petite application pour mon téléphone portable avec J2ME .. Au début ça paraissais stylé à faire (bon en même temps, y avais pas la possibilité d'utiliser SQLite & co), mais dès que les besoins (surtout les tris) se sont compliqués un poil, bordel ce que c'est devenu casse couille à coder ...
Après tout dépend de la complexité de ton truc .. Je conseillerais effectivement pas Oracle pour un logiciel qui permet à ma mère de savoir ce qu'elle a acheté chez l'épicier la semaine passée