SQLite est un moteur libre de base de données relationnelles aux possibilités fantastiques. Disons en deux mots qu'il a tout d'un grand, mais avec une empreinte mémoire de 125 ko... et en n'utilisant qu'un unique fichier de stockage !
Le recours à l'une de ses deux extensions client-serveur existantes permet d'utiliser SQLite au sein d'une application web. Mais là où SQLite se révèle imbattable, c'est embarqué au sein d'une application : on bénéficie ainsi de toute la puissance d'un moteur relationnel et du langage SQL, tout ça sans avoir déployé aucun serveur, puisque tout tient dans un unique fichier, tables, vues, index, etc...
Je profite donc de cette news pour encourager vivement tout développeur de logiciel libre à considérer sérieusement l'usage de SQLite dans son application : laisser à un moteur dédié le soin de stocker ses données, c'est pertinent pour toutes les applications, pas seulement pour le client-serveur. Et dans cette optique, SQLite est en passe de devenir incontournable...
NdM : SQLite est dans le domaine public.
![[en]](../images/en.png)
Le projet SQLite (3925 hits)-
Changements apportés par la version 3.0 (781 hits)
-
Un article sur SQLite publiée dans Linuxjournal (1023 hits)
-
Utilisez SQLite avec le langage de votre choix (2127 hits)
-
Liste non-exhaustive des projets utilisant SQLite (1562 hits)
> Lire la dépêche (140 commentaires, moyenne: 3,4).
Vous avez demandé le commentaire #438684.
Run by 
Cette page a été générée par Templeet en 0.0679s (dont 0.0063 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
revenons sur terre
SQLite est un moteur libre de base de données relationnelles aux possibilités fantastiques. Disons en deux mots qu'il a tout d'un grand,
Bémol. La limitation fondamentale de SQLite est son modèle de verrouillage rudimentaire, même comparé à MySQL. En effet, toute requête en écriture et même toute transaction ouverte sur la base verrouille toute la base de façon exclusive.
« Multiple processes can have the same database open at the same time. Multiple processes can be doing a SELECT at the same time. But only one process can be making changes to the database at once.
[...]
Locking in SQLite is very course-grained. SQLite locks the entire database. »
http://sqlite.org/faq.html#q7(...)
Autre point notable :
« An attempt to execute COMMIT might result in an SQLITE_BUSY return code. This indicates that another thread or process had a read lock on the database that prevented the database from being updated. When COMMIT fails in this way, the transaction remains active and the COMMIT can be retried later after the reader has had a chance to clear. »
http://sqlite.org/lang.html#transaction(...)
[^]Re: revenons sur terre
il ne peut y avoir plus d'un acces simultané en ecriture sur un element.
etant donné l'impossibilité dans les fondements du modele relationel, de faire une fermeture transitive, il est impossible de mettre un verrou sur un tuple et maintenir l'integrite referentielle.
tout au plus, il est possible de mettre un lock sur les tables concernés jusqu'à une certaine profondeur. ou par mesure de securité, mettre un verrou sur la base elle meme.
la solution pour gerer ca, serait de mettre des versions de tuples. à partir de là, il est possible d'avoir une trace temporelle dans la base. par contre cela necessite d'ajourner l'evolution des jointures.
pour le moment, je ne connais pas de solution type "SQL over CVS/arch/subversion". pour le contraire, il y a les Wiki SQL, mais l'integrité du contenu n'est pas garantie.
pour le second point, MDR PTDR LOL ROTLF ! le lock en lecture ca devrait etre breveté ! chepa, au royaume de la photocopie, du P2P, de l'industriel à l'instar du sur mesure, dire cela merite un certain courage, et puis faire du Copy On Write n'est pas si compliqué.
[^]Re: revenons sur terre
pour le dernier point :
tu oublies pas qu'il existe des "shared lock", en plus des "exclusive lock" ?
(le lock en lecture sert simplement à éviter qu'un gars qui veuille modifier l'information puisse le faire directement, sans que les lecteurs soient informés... si il constate un shared lock, il doit (théoriquement) attendre qu'ils n'y en ait plus avant de poser un xlock pour modifier...
in mon cours de base de donnée, qu'il m'a l'air juste quand même
Gougueul bombons ensemble :)
[^]Re: revenons sur terre
le principe du lock fichier est un principe de lock atomique dans le cadre d'absence de gestion de la copie d'edition.
tu fais la meme chose sur un CVS avec "edit" et "unedit". une maniere de gerer cela sur un SGBD vient à n'avoir qu'une transaction effective sur un element ( base, table, tuple, attribut ), et de faire une copie de l'element concerné pour le remplacer au COMMIT. le Copy On Write permet d'aleger le systeme et de le rendre plus veloce.
Par contre avec la notion de copie des transactions, cela evite d'avoir un readlock sur l'element en cours de transaction et donc de garantir l'integrite et l'atomicite du commit. avec un readolck le commit n'est plus atomique mais devient element transactionnel qui doit etre annulé en cas de readlock. ce qui fait dans le cas de SQLite, le code erreur retourné pour rejouer plus tard la transaction.
conclusion dans un systeme critique à lecture forte, le commit n'est pas priorisé et peut en cascade, perturber l'integrité globale d'un systeme.
[^]Re: revenons sur terre
Pas bien compris. Tu peut filer une source plus détaillées de comment un "copy on write" peut améliorer ou rendre inutile (pas bien co;pris ton propos) les locks, et rendre le dbms plus véloce ? J'ai fait une rapide recherche sur google et je vois pas...
[^]Re: revenons sur terre
- Qu'appelles tu une "fermeture transitive" ?
- Qu'appelles tu la "profondeur" d'une table ? ("mettre un lock sur les tables concernés jusqu'à une certaine profondeur")
- "mettre des versions de tuples" : tu parles des log des transactions par le DBMS ?
- "le lock en lecture ca devrait etre breveté" : pourquoi au juste ?
[^]Nan, je plane toujours comme le Big Lebowski !!
Les extraits que tu donnes décrivent le comportement des versions 2.x de SQLite. Pour la version 3.0, cf. mon résumé, ou:
SQLite version 3.0 allows one process to begin writing the database while other processes continue to read. The writer must still obtain an exclusive lock on the database for a brief interval in order to commit its changes, but the exclusive lock is no longer required for the entire write operation. A more detailed [1] report on the locking behavior of SQLite version 3.0 is available separately.
[1] File Locking And Concurrency In SQLite Version 3
http://www.sqlite.org/lockingv3.html(...)
Voir aussi les deux extensions client-serveur que j'ai citées.
Bref, pas de quoi "revenir sur terre", comme tu dis si gentiment.
[^]Oui, mais... [workaround]
Bémol. La limitation fondamentale de SQLite est son modèle de verrouillage rudimentaire, même comparé à MySQL. En effet, toute requête en écriture et même toute transaction ouverte sur la base verrouille toute la base de façon exclusive.
Bémol sur ton bémol : si tu lis un peu plus loin, tu verras qu'une solution est proposée pour pouvoir verouiller sur des tables : stocker une table par base (donc par fichier) et attacher les bases entre elles pour que le SGBD les voie comme une base unique :
A limited form of table-level locking is now also available in SQLite. If each table is stored in a separate database file, those separate files can be attached to the main database (using the ATTACH command) and the combined databases will function as one. But locks will only be acquired on individual files as needed. So if you redefine "database" to mean two or more database files, then it is entirely possible for two processes to be writing to the same database at the same time. To further support this capability, commits of transactions involving two or more ATTACHed database are now atomic.
c'est sûr, c'est quand même assez contraignant...
L'idéal serait, je pense, de pouvoir spécifier le mode de stockage des tables lors de la création de la base (dans un fichier unique pour toutes les tables, ou dans un répertoire unique avec des fichiers distincts par table). Et là on aurait à moindres frais un verouillage au niveau de la table...
Je vais envoyer un e-mail au mainteneur pour lui proposer l'idée.
#define MAGIC 0xdefaced /* I should've patented this number -cliph */
[^]Re: Oui, mais... [workaround]
L'idéal serait, je pense, de pouvoir spécifier le mode de stockage des tables lors de la création de la base (dans un fichier unique pour toutes les tables, ou dans un répertoire unique avec des fichiers distincts par table). Et là on aurait à moindres frais un verouillage au niveau de la table...
On va finir par réinventer MySQL :)
[^]Re: Oui, mais... [workaround]
Pffff, c'est limite du mauvais esprit ca :) Il faut prendre les bonnes choses là ou elles sont, et même avec ce genre de fonctionnalités, SQLite resterait beaucoup moins lourd que MySQL et garderait ses qualités parfaitement adaptées à l'embarqué.
Blague à part, tous les SGBD font face aux mêmes problèmes (le stockage et la gestion d'accès concurrents) avec les mêmes moyens (un système de fichiers X ou Y). Il est normal qu'on arrive parfois, voire souvent, aux mêmes solutions, non ?
#define MAGIC 0xdefaced /* I should've patented this number -cliph */
[^]Re: Oui, mais... [workaround]
Sans vouloir faire de mauvais esprit, j'ai pas a me demander comment est foutu la table en dessous pour faire des jointures multi tables avec SQLite, avec MySQL, bonjour les suprises .....
Bref, y'a peut etre moins de gadgets sur SQLLite mais au moins y'a du SQL ....
j'ai trollé, ca y'est j'ai trollé, c'est plus fort que moi ...