plus facile de faire des requêtes plus compliquées, on est sûrs que les modifications sont atomiques, que l'état de la configuration va être consistant tout le temps, et on est un peu protégés d'un crash ou d'une coupure d'électricité au moment d'écriture
Faire des requêtes compliquées sur de la configuration? Je vais t'épargner mon laïus par la preuve en regardant les fichiers sqlite de FF, mais il y a plus d'un fichier qui ne contiens qu'une seule table (oh allez, des exemples quand même: cookies.sqlite...sigh..., permissions.sqlite). Que veux-tu faire de complexe avec une seule table?
La configuration, ce n'est pas le truc que l'on est censés charger au démarrage, et qui doit donc être assez simple pour être chargé vite (autrement dit l'opposé d'une requête compliquée)?
Très franchement, je pense que quand on commence à utiliser une base de données relationnelle pour stocker de la configuration (qui est typiquement soit un script, mais je ne trouve pas non plus cette solution élégante, soit une BDD clé-valeur, l'idéal, après, je peux encore accepter que le format ne soit pas du texte brut, pourquoi pas, ça peut nécessiter de la compression par exemple... admettons.) c'est qu'il y a un problème de sur-ingénierie. Et même si certains logiciels en souffrant sont excellents et même si je les utilise, ça ne veut pas dire que je le cautionnerai.
L'intérêt majeur d'un SGBDR c'est le côté relationnel des données, pas spécialement la consistance ni l'atomicité: ces points sont partagés par plein d'autres SGBD. Penses-tu que berkeleydb (libdb, le truc qui gère entres autres /etc/passwd) ne soit pas consistante ni atomique? Et les SGBD NoSQL (not only, pour rappel)? Que le support final soit un fichier texte n'a rien à voir avec la résilience, l'important c'est comment ce fichier est manipulé.
Pour ce qui est des modifications d'écriture et de la protection contre un arrêt au pire moment, c'est très facile avec des fichiers bruts (pas juste texte, tu noteras): on crée un fichier, on écrit dedans, on swap les noms (d'ailleurs, dommage qu'il n'y ait aucune commande shell pour le faire) et on vire le fichier de backup. Voire on le garde, pour future comparaison.
Ah, tiens, une fonctionnalité que les SGBDR n'ont pas, et qui est utile pour de la configuration ça: le versionning. Enfin, je mens, on pourrait versionner les CVS... mais niveau lisibilité c'est pas top.
Et puis sqlite c'est quand même une base de donnée avec un seul fichier et zéro configuration à faire, c'est plutôt sympa comme fichier de stockage, je trouve.
Non mais sérieusement, je le pensais quand je disais que j'aime bien sqlite. Cet aspect est très sympa, je suis d'accord. D'ailleurs, je ne connais qu'un seul autre SGBDR qui le permette: firebird.
Maintenant, si je reprend le cas FF (le seul installé sur mon système dont j'aie trouvé les fichiers sqlite, désolé si je donne l'impression de m'acharner) il n'y a justement pas qu'un seul fichier.
Je parle bien dans ce message d'une critique des logiciels configurés par sql, pas des logiciels qui utilisent le sql pour des formats de données (par exemple dans le cas de fossil je pense que c'est pertinent, il y a un wiki, un bug tracker, et un DVCS. Pour le wiki et le DVCS c'est évident que c'est utile, et compte tenu de l'intégration du BT avec le DVCS, pourquoi pas).
[^] # Re: Fossil
Posté par freem . En réponse au journal Le danger github. Évalué à 3.
Faire des requêtes compliquées sur de la configuration? Je vais t'épargner mon laïus par la preuve en regardant les fichiers sqlite de FF, mais il y a plus d'un fichier qui ne contiens qu'une seule table (oh allez, des exemples quand même: cookies.sqlite...sigh..., permissions.sqlite). Que veux-tu faire de complexe avec une seule table?
La configuration, ce n'est pas le truc que l'on est censés charger au démarrage, et qui doit donc être assez simple pour être chargé vite (autrement dit l'opposé d'une requête compliquée)?
Très franchement, je pense que quand on commence à utiliser une base de données relationnelle pour stocker de la configuration (qui est typiquement soit un script, mais je ne trouve pas non plus cette solution élégante, soit une BDD clé-valeur, l'idéal, après, je peux encore accepter que le format ne soit pas du texte brut, pourquoi pas, ça peut nécessiter de la compression par exemple... admettons.) c'est qu'il y a un problème de sur-ingénierie. Et même si certains logiciels en souffrant sont excellents et même si je les utilise, ça ne veut pas dire que je le cautionnerai.
L'intérêt majeur d'un SGBDR c'est le côté relationnel des données, pas spécialement la consistance ni l'atomicité: ces points sont partagés par plein d'autres SGBD. Penses-tu que berkeleydb (libdb, le truc qui gère entres autres /etc/passwd) ne soit pas consistante ni atomique? Et les SGBD NoSQL (not only, pour rappel)? Que le support final soit un fichier texte n'a rien à voir avec la résilience, l'important c'est comment ce fichier est manipulé.
Pour ce qui est des modifications d'écriture et de la protection contre un arrêt au pire moment, c'est très facile avec des fichiers bruts (pas juste texte, tu noteras): on crée un fichier, on écrit dedans, on swap les noms (d'ailleurs, dommage qu'il n'y ait aucune commande shell pour le faire) et on vire le fichier de backup. Voire on le garde, pour future comparaison.
Ah, tiens, une fonctionnalité que les SGBDR n'ont pas, et qui est utile pour de la configuration ça: le versionning. Enfin, je mens, on pourrait versionner les CVS... mais niveau lisibilité c'est pas top.
Non mais sérieusement, je le pensais quand je disais que j'aime bien sqlite. Cet aspect est très sympa, je suis d'accord. D'ailleurs, je ne connais qu'un seul autre SGBDR qui le permette: firebird.
Maintenant, si je reprend le cas FF (le seul installé sur mon système dont j'aie trouvé les fichiers sqlite, désolé si je donne l'impression de m'acharner) il n'y a justement pas qu'un seul fichier.
Je parle bien dans ce message d'une critique des logiciels configurés par sql, pas des logiciels qui utilisent le sql pour des formats de données (par exemple dans le cas de fossil je pense que c'est pertinent, il y a un wiki, un bug tracker, et un DVCS. Pour le wiki et le DVCS c'est évident que c'est utile, et compte tenu de l'intégration du BT avec le DVCS, pourquoi pas).