Bien sûr que ça n'est pas aussi simple, j'ai volontairement grossi le trait mais tout ça reste valable pour l'écrasante majorité des applications présentes sur un poste de bureau sous Linux.
Mon discours s'adressait aux développeurs de logiciels de tous les jours, de clients RSS, de lecteurs de news, de générateurs d'albums photo, de montage vidéo, de tableurs, etc. Pour tous ces usages l'emploi de SQLite pour la gestion de la persistance de ses données est très pertinent, je le maintiens.
Inversement, je veux bien que tu me cites une seule application d'une distribution Mandrake (au hasard) qui ait potentiellement affaire à une fermeture transitive sur un arbre de 10 000 noeuds puis sur un graphe ( non fortement connexe ) contenant des cycles du meme nombre de noeuds... Honnêtement, c'est un peu pousser mémé dans les orties, non ?
le relationnel n'est pas une panacée, et ces 5 questions expose certains points faibles theoriques et pratiques du model
Ouais mais il s'agit pas de discuter de théorie et des faiblesses du modèle relationnel. Les utilisateurs de centaines de milliers d'applications client-serveur se disent pas tous les jours "ah merde, mes données sont stockées dans un SGBD relationnel, dont le modèle a des points faibles, quelle angoisse !!"
Mon propos était de proposer la puissance et la souplesse d'un SGBDR embarqué pour gérer les données d'une bête application autonome de tous les jours. Grâce à SQLite ça n'est pas réservé au client-serveur !
La question qui mérite d'être posée, c'est, plutôt que de réinventer la roue, un format de stockage de données, du code pour assurer la lecture / l'écriture / le traitement de ces données, pourquoi ne pas utiliser SQLite ? Pour les types d'applications que j'ai citées, on a tout à y gagner.
Et puisque tu sembles si bien connaître le modèle relationnel, pourquoi ne pas m'aider à défendre ce point de vue pour ce genre d'applications ?
Tu veux nourrir le troll ou lancer un débat constructif ?
[^] # Re: explosion du trokilometre
Posté par bobert . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 10.
Bien sûr que ça n'est pas aussi simple, j'ai volontairement grossi le trait mais tout ça reste valable pour l'écrasante majorité des applications présentes sur un poste de bureau sous Linux.
Mon discours s'adressait aux développeurs de logiciels de tous les jours, de clients RSS, de lecteurs de news, de générateurs d'albums photo, de montage vidéo, de tableurs, etc. Pour tous ces usages l'emploi de SQLite pour la gestion de la persistance de ses données est très pertinent, je le maintiens.
Inversement, je veux bien que tu me cites une seule application d'une distribution Mandrake (au hasard) qui ait potentiellement affaire à une fermeture transitive sur un arbre de 10 000 noeuds puis sur un graphe ( non fortement connexe ) contenant des cycles du meme nombre de noeuds... Honnêtement, c'est un peu pousser mémé dans les orties, non ?
le relationnel n'est pas une panacée, et ces 5 questions expose certains points faibles theoriques et pratiques du model
Ouais mais il s'agit pas de discuter de théorie et des faiblesses du modèle relationnel. Les utilisateurs de centaines de milliers d'applications client-serveur se disent pas tous les jours "ah merde, mes données sont stockées dans un SGBD relationnel, dont le modèle a des points faibles, quelle angoisse !!"
Mon propos était de proposer la puissance et la souplesse d'un SGBDR embarqué pour gérer les données d'une bête application autonome de tous les jours. Grâce à SQLite ça n'est pas réservé au client-serveur !
La question qui mérite d'être posée, c'est, plutôt que de réinventer la roue, un format de stockage de données, du code pour assurer la lecture / l'écriture / le traitement de ces données, pourquoi ne pas utiliser SQLite ? Pour les types d'applications que j'ai citées, on a tout à y gagner.
Et puisque tu sembles si bien connaître le modèle relationnel, pourquoi ne pas m'aider à défendre ce point de vue pour ce genre d'applications ?
Tu veux nourrir le troll ou lancer un débat constructif ?