Voilàààà ! Voilà l'idée intelligente: Plutôt que des formats binaires imbitable (coucou Microsoft) ou de l'XML-de-la-mort lourdinge (ou même - *ouch* - des documents XML zippé, coucou MSOffice/LibreOffice), ou encore YAML/jSon/le-fomat-de-mon-beau-frère, le développeur de ce logiciel de retouche photo a choisit SQLite comme format de sauvegarde de son application. Il s'en explique.
Personnellement, après des années à avoir développé et travaillé avec différents formats, avec des fichiers de différentes tailles, sur de multiples plateformes, ce choix devient de plus en plus évident:
• Pas de codec ou parseur maison à écrire pour votre format: On élimine ce pan de bugs potentiels.
• SQLite est un format portable: Prenez tel quel votre fichier, il est lisible partout, du PC à l'iPhone/Android (qui incluent SQLite en standard).
• Little-endian ? Big-endian ? On s'en fout: SQLite rend cela transparent.
• SQLite est lisible de tous les langages. Tout simplement. (SQLite est une lib qui peut s'intégrer statiquement dans vos applications, et elle ne fait que 230 ko)
• Le format SQLite est remarquablement stable depuis de nombreuses années (Le dernier changement de format date de 2006). C'est donc pérenne.
• SQLite peut se bouffer un fichier de 2 Go sans problème. Essayez avec un fichier XML.
• La lecture est ultra-performante (indexation), exprimée efficacement (requêtes SQL) et permet des opérations complexes (jointures, filtres, tri...). Essayez avec XML. XPath est terriblement pauvre à côté de ce que permet SQL.
• Mettre à jour un gros fichier ? Un UPDATE mettra à jour juste les parties modifiées: Vous n'avez pas tout le fichier à ré-écrire. Essayez de modifier juste une partie d'un gros fichier XML: Bonheur.
• SQLite supporte nativement le stockage de données binaires: Pas de base64 à la con en comme en XML.
• Débuguer un fichier de données ? Pas d'éditeur hexa à utiliser et d'offsets à calculer: Juste un front-end SQLite à utiliser.
• Enfin, SQLite est ACID et gère les transactions: Impossible de corrompre le fichier. Soit tout est écrit, soit rien du tout. Vos données sont toujours dans un état cohérent. Une coupure de courant en pleine sauvegarde ? Même pas mal !
C'est juste magnifique. Ces caractéristiques en font un excellent format d'enregistrement pour vos applications.
En prime, cela ouvre la possibilité de relire le fichier dans d'autres applications. Les données ne sont pas enfermées.
(La structure de la base étant incluse dans le fichier SQLite, c'est tout aussi auto-descriptif qu'un fichier XML.)
Ce n'est pas pour rien que Mozilla, Adobe, McAfee, Nokia, Bloomberg, Symbian et Oracle financent SQLite (qui est développé par une unique personne).
(oui je sais, je suis chiant avec SQLite, mais cette lib est juste magnifique par son efficacité et sa fiabilité à toute épreuve.)
EDIT: D'autres développeurs ont également fait ce choix:
http://mapbox.com/developers/mbtiles/
http://stackful-dev.com/sqlite-the-case-against-custom-application-file-formats
(Permalink)
