Merci d'avoir pris le temps de répondre de manière aussi détaillée.
Il est vrai que les perspectives d'amélioration des temps d'ouverture et d'enregistrement des documents Libre Office font quand même bien envie.
Concernant la pérennité du format, l'équipe SQLite s'engage à rester rétro-compatible avec le format SQLite3 jusqu'en 2050 a minima, ce qui semble tout à fait important à l'heure de "l'agilité" parfois mal comprise et pouvant confiner à l'agitation marketing (marketing dont SQLite n'est pas exempte, mais a minima plus dans le fait de changer le format de fichier). Mais effectivement zip a eu 10 ans d'avance et une plus grande stabilité dans les faits, et c'était encore plus vrai au moment de la création des standards en question.
Pour ce qui est de l'inexistence d'implémentations tierces, c'est bien sûr vrai (modulo les 2 ou 3 que tu mentionnes) mais c'est peut-être lié au fait que la bibliothèque officielle soit dans le domaine public et écrite en C ANSI et très compacte donc facilement adaptable à tout système sans avoir à réinventer la roue.
Pour ce qui est du "découpage du contenu en tables, avec des relations entre les tables et cie", ce n'est pas ce que j'ai compris de la fin de l'article, qui au contraire souligne le fait qu'on peut tout à fait stocker du XML (avec les namespaces donc) dans des tables SQL, en gagnant en plus la possibilité de les versioner et indexer plus facilement. Je reprends juste ce passage :
"Some readers might be reluctant to consider SQLite as an application file format because they have been inculcated with the idea that all SQL database schemas must be factored into third normal form and store only small primitive data types such as strings and integers. Certainly relational theory is important and designers should strive to understand it. But, as demonstrated above, it is often quite acceptable to store complex information as XML or JSON in text fields of a database."
Mais les autres points sont aussi abordés.
Après je te suis sur l'inertie importante en terme d'habitude de formats de fichiers, mais si on divise par 10 le temps d'ouverture et d'enregistrement ça pourrait booster l'adoption (la passer de 20 ans à 10 ans ?).
Il ne reste plus qu'à (re?)lancer le sujet auprès de l'OASIS, comme tu le suggères :-)
[^] # Re: Un (petit) peu HS : SQLite ?
Posté par Papey . En réponse à la dépêche Hotspot, à la recherche du point chaud.... Évalué à 7.
Merci d'avoir pris le temps de répondre de manière aussi détaillée.
Il est vrai que les perspectives d'amélioration des temps d'ouverture et d'enregistrement des documents Libre Office font quand même bien envie.
Concernant la pérennité du format, l'équipe SQLite s'engage à rester rétro-compatible avec le format SQLite3 jusqu'en 2050 a minima, ce qui semble tout à fait important à l'heure de "l'agilité" parfois mal comprise et pouvant confiner à l'agitation marketing (marketing dont SQLite n'est pas exempte, mais a minima plus dans le fait de changer le format de fichier). Mais effectivement zip a eu 10 ans d'avance et une plus grande stabilité dans les faits, et c'était encore plus vrai au moment de la création des standards en question.
Pour ce qui est de l'inexistence d'implémentations tierces, c'est bien sûr vrai (modulo les 2 ou 3 que tu mentionnes) mais c'est peut-être lié au fait que la bibliothèque officielle soit dans le domaine public et écrite en C ANSI et très compacte donc facilement adaptable à tout système sans avoir à réinventer la roue.
Pour ce qui est du "découpage du contenu en tables, avec des relations entre les tables et cie", ce n'est pas ce que j'ai compris de la fin de l'article, qui au contraire souligne le fait qu'on peut tout à fait stocker du XML (avec les namespaces donc) dans des tables SQL, en gagnant en plus la possibilité de les versioner et indexer plus facilement. Je reprends juste ce passage :
"Some readers might be reluctant to consider SQLite as an application file format because they have been inculcated with the idea that all SQL database schemas must be factored into third normal form and store only small primitive data types such as strings and integers. Certainly relational theory is important and designers should strive to understand it. But, as demonstrated above, it is often quite acceptable to store complex information as XML or JSON in text fields of a database."
Mais les autres points sont aussi abordés.
Après je te suis sur l'inertie importante en terme d'habitude de formats de fichiers, mais si on divise par 10 le temps d'ouverture et d'enregistrement ça pourrait booster l'adoption (la passer de 20 ans à 10 ans ?).
Il ne reste plus qu'à (re?)lancer le sujet auprès de l'OASIS, comme tu le suggères :-)