Je comprends tes choix et SQLite ne permettra effectivement jamais (sauf à inclure la bibliothèque dans de prochaines version des explorateurs de fichiers) d'explorer les données sans programme dédié.
Quelques précisions par rapports aux autres points évoqués. A partir du moment où aucune transaction en écriture n'est en cours tu peux sauvegarder une base SQLite en copiant simplement le fichier de la base, par FTP ou par un autre moyen, en même temps que les autres fichiers de l'application. Et en général même si une transaction en écriture est en cours, le fichier ne sera pas corrompu, même si en toute rigueur ce n'est pas garanti.
Pour ce qui est des accès concurrents, ce qui est problématique c'est lorsque plusieurs processus différents essaient d'accéder au même fichier SQLite à travers le réseau, à partir d'ordinateurs différents. Ce sont les imperfections de la gestion des accès à des systèmes de fichiers distants par les systèmes d'exploitation qui ne garantit pas que toutes les modifications apportées dans ce cas le seront de manière cohérente : SQLite ne peut pas imposer explicitement un vidage des tampons à la fin des transactions avec l'assurance que les modifications seront effectivement écrites physiquement sur le support cible. Chaque ordinateur pourra donc potentiellement avoir une vision un peu différente du fichier SQLite.
Cependant si un logiciel serveur centralise les accès via le web à l'application, et que seule l'application accède à la base de données, a priori la base SQLite est soit sur le disque physique associé à l'ordinateur où tourne l'application, et la bibliothèque SQLite peut donc s'assurer du vidage effectif des tampons, soit l'application utilise la même pile d'accès à un répertoire réseau, et a priori les différents processus / threads devraient avoir la même vue sur l'état du fichier, mais cela dépend peut-être du protocole réseau utilisé et de sa manière de gérer localement les accès concurrents aux ressources distantes.
Dans le cas où SQLite peut contrôler efficacement les tampons d'accès en écriture à la base de données, il n'y a aucun problème de concurrence : SQLite est pleinement ACID, chaque processus a une vue purement transactionnelle sur la base et les différents processus ou threads font simplement la queue pour écrire dans la base, avec en général de très bonnes performances.
Quoi qu'il en soit, dans de nombreux cas les accès concurrents à une base SQLite sont plus simples à gérer que des accès concurrents à d'autres types de fichiers binaires ou texte, dans la mesure ou SQLite gère pour toi les mécanismes de gestion de la concurrence (mutex ou autres), et que les problèmes d'asymétrie dans les accès au réseau touche aussi les autres types de fichiers que tu pourrais utiliser.
[^] # Re: SGBDR
Posté par Papey . En réponse à la dépêche Quick & Dirty Repository (QDRep). Évalué à 5. Dernière modification le 04 mai 2021 à 09:33.
Je comprends tes choix et SQLite ne permettra effectivement jamais (sauf à inclure la bibliothèque dans de prochaines version des explorateurs de fichiers) d'explorer les données sans programme dédié.
Quelques précisions par rapports aux autres points évoqués. A partir du moment où aucune transaction en écriture n'est en cours tu peux sauvegarder une base SQLite en copiant simplement le fichier de la base, par FTP ou par un autre moyen, en même temps que les autres fichiers de l'application. Et en général même si une transaction en écriture est en cours, le fichier ne sera pas corrompu, même si en toute rigueur ce n'est pas garanti.
Pour ce qui est des accès concurrents, ce qui est problématique c'est lorsque plusieurs processus différents essaient d'accéder au même fichier SQLite à travers le réseau, à partir d'ordinateurs différents. Ce sont les imperfections de la gestion des accès à des systèmes de fichiers distants par les systèmes d'exploitation qui ne garantit pas que toutes les modifications apportées dans ce cas le seront de manière cohérente : SQLite ne peut pas imposer explicitement un vidage des tampons à la fin des transactions avec l'assurance que les modifications seront effectivement écrites physiquement sur le support cible. Chaque ordinateur pourra donc potentiellement avoir une vision un peu différente du fichier SQLite.
Cependant si un logiciel serveur centralise les accès via le web à l'application, et que seule l'application accède à la base de données, a priori la base SQLite est soit sur le disque physique associé à l'ordinateur où tourne l'application, et la bibliothèque SQLite peut donc s'assurer du vidage effectif des tampons, soit l'application utilise la même pile d'accès à un répertoire réseau, et a priori les différents processus / threads devraient avoir la même vue sur l'état du fichier, mais cela dépend peut-être du protocole réseau utilisé et de sa manière de gérer localement les accès concurrents aux ressources distantes.
Dans le cas où SQLite peut contrôler efficacement les tampons d'accès en écriture à la base de données, il n'y a aucun problème de concurrence : SQLite est pleinement ACID, chaque processus a une vue purement transactionnelle sur la base et les différents processus ou threads font simplement la queue pour écrire dans la base, avec en général de très bonnes performances.
Quoi qu'il en soit, dans de nombreux cas les accès concurrents à une base SQLite sont plus simples à gérer que des accès concurrents à d'autres types de fichiers binaires ou texte, dans la mesure ou SQLite gère pour toi les mécanismes de gestion de la concurrence (mutex ou autres), et que les problèmes d'asymétrie dans les accès au réseau touche aussi les autres types de fichiers que tu pourrais utiliser.