SQLite Release 3.6.19 : Gestion des clés étrangères

SQLite Release 3.6.19 On 2009 Oct 14 (3.6.19)

Citation:

---

Changes associated with this release include the following:

* Added support for foreign key constraints. Foreign key constraints are disabled by default. Use the foreign_keys pragma to turn them on.
* Generalized the IS and IS NOT operators to take arbitrary expressions on their right-hand side.
* The TCL Interface has been enhanced to use the Non-Recursive Engine (NRE) interface to the TCL interpreter when linked against TCL 8.6 or later.
* Fix a bug introduced in 3.6.18 that can lead to a segfault when an attempt is made to write on a read-only database.

---

Que pensez-vous de cette nouveauté ?
Va-t-elle permettre un nouveau regain d'intérêt pour cette base de données ?

Voilà qui invalide mon affirmation d'hier...

J'ai essayé il y a 1-2 ans d'insérer tout le contenu d'en-tête d'un newsgroup dans sqlite (uniqueID / Groupe / ArticleId / titre / auteur/ date). Les performance en ajout étaient impressionnantes jusqu'à 100'000 enregistrements (4-5000 insertions secondes). Par contre passé le million ça tombait dans les 200/sec.

A ce que j'ai pu lire, cette lenteur viendrait des contraintes d'unicité qui sont des btree et non des hash index. Je me demande si ce problème est d'actualité.

Citation:

---

Envoyé par Emmanuel Lecoester

SQLite Release 3.6.19 On 2009 Oct 14 (3.6.19)



Que pensez-vous de cette nouveauté ?
Va-t-elle permettre un nouveau regain d'intérêt pour cette base de données ?

---

Absolument génial \o/.

J'espère que ça sera vite implanté à peu près partout (sur les distribs linux en tout cas), comme ca ou pourra commencer à l'utiliser dans nos programmes, car la c'était tout à fait possible, mais il fallait passer par des générateurs de triggers, c'est un peu lourd quand on a une dixaine de tables ou plus ...

ça va vraiment accélérer les choses je pense. Mais j'attend de tester voir ce que ça donne par rapport à mon bien aimé SqlServeur:ccool:

Citation:

---

Envoyé par sidev

ça va vraiment accélérer les choses je pense. Mais j'attend de tester voir ce que ça donne par rapport à mon bien aimé SqlServeur:ccool:

---

C'est pas du tout la même utilisation, sqlite étant une BDD embarquée (ou alors il faut utiliser SQL Server CE, mais je sais pas où ca en est niveau fonctionnalités).
SQLite est de plus en plus utilisée, beaucoup d'applis Linux l'utilisent, c'est la BDD intégrée à MacOS (et sa version mobile) et Android, ...
Personnelement je l'utilise en C#, ce qui me permet de faire fonctionner mes applis aussi bien sur Linux/OS X avec Mono que sur Windows avec .NET :)
Le fait qu'elle évolue bien devrait se ressentir sur les applications qui l'utilisent :ccool:

Edit:
Il manque tout de même pour moi quelques petites choses à SQLite pour rendre son utilisation vraiment agréable:
* Pouvoir mettre des sous-requêtes dans les contraintes ;
* Les vues modifiables (on peut s'en passer avec des triggers INSTEAD OF) ;
* Plus de fonctions intégrées: il n'y a presque pas de fonctions mathématiques (SQRT, SIN, ...) par exemple;
* Un index FULLTEXT.

Mais comme dit plus haut, l'objectif de SQLite n'est pas de gérer des grosses tables (> 200 000 enregistrements). En théorie, une application qui utilise SQLite ne devrait jamais arriver à cette limite, si c'est le cas, il faut passer son chemin. Par exemple, Banshee utilise SQLite pour gérer sa bibliothèque multimedia, et c'est vraiment efficace et rapide, comparé à ses concurrents, ...

Citation:

---

Envoyé par Rapha222

(ou alors il faut utiliser SQL Server CE, mais je sais pas où ca en est niveau fonctionnalités).
...

---

Même si SQL Server CE et Sqlite joue dans la même catégorie il faut signaler que
Sqlite est très simple (c'est ça qui fait sa force). SQL Server CE est plus complexe d'autant plus qu'il fournit des fonctionnalités bcp plus avancés.

Citation:

---

Envoyé par sidev

Même si SQL Server CE et Sqlite joue dans la même catégorie il faut signaler que
Sqlite est très simple (c'est ça qui fait sa force). SQL Server CE est plus complexe d'autant plus qu'il fournit des fonctionnalités bcp plus avancés.

---

Je ne connais pas très bien SQL Server CE, car j'utilise principalement Mono.
Tu saurais rapidement donner ce qu'il y a en moins dans la CE par rapport à la version serveur ou/et ce que CE supporte par rapport à SQLite (par example, support-il les requêtes récursives, comme la version serveur ?).

Merci

Citation:

---

Envoyé par Rapha222

Je ne connais pas très bien SQL Server CE, car j'utilise principalement Mono.
Tu saurais rapidement donner ce qu'il y a en moins dans la CE par rapport à la version serveur ou/et ce que CE supporte par rapport à SQLite (par example, support-il les requêtes récursives, comme la version serveur ?).

Merci

---

La récursivité non je pense pas. Mais il offre plus de fonctions math que Sqlite.
On peut même faire de la réplication de données avec SqlServer 2000 et ultérieurs :ccool: , ceci fait partie de ces nouvelles fonctionnalités.

Citation:

---

Envoyé par sidev

ça va vraiment accélérer les choses je pense. Mais j'attend de tester voir ce que ça donne par rapport à mon bien aimé SqlServeur:ccool:

---

lequel?

mysql, oracle, db2?

Citation:

---

Envoyé par robert_trudel

lequel?

mysql, oracle, db2?

---

Non, SQL Server, il l'a dit ^^'

Citation:

---

Envoyé par Rapha222

Mais comme dit plus haut, l'objectif de SQLite n'est pas de gérer des grosses tables (> 200 000 enregistrements). En théorie, une application qui utilise SQLite ne devrait jamais arriver à cette limite, si c'est le cas, il faut passer son chemin. Par exemple, Banshee utilise SQLite pour gérer sa bibliothèque multimedia, et c'est vraiment efficace et rapide, comparé à ses concurrents, ...

---

Je suis en désaccord avec ça : un SGBD qui ne peut pas tenir la charge serait à éviter absolument (tous les projets grossissent). Ce n'est pas le cas d'sqLite :
Mon projet a commencé à 100 lignes, il approche aujourd'hui le million et j'espere bien qu'il ira jusq'à 50 M pourquoi n'irait-il pas ? contrairement à access il ne connait pas de chute brutale de perf mais je n'ai pas encore testé à pleine charge.

Citation:

---

Envoyé par unBonGars

Je suis en désaccord avec ça : un SGBD qui ne peut pas tenir la charge serait à éviter absolument (tous les projets grossissent). Ce n'est pas le cas d'sqLite :
Mon projet a commencé à 100 lignes, il approche aujourd'hui le million et j'espere bien qu'il ira jusq'à 50 M pourquoi n'irait-il pas ? contrairement à access il ne connait pas de chute brutale de perf mais je n'ai pas encore testé à pleine charge.

---

Je répondais juste au commentaire de _skip. SQLite n'est pas fait pour gérer des quantités astronomiques de données, si c'est le cas, c'est qu'il faut passer à autre chose: un SGBD sur un machine dédiée.

Comme c'est mis sur le site officiel:

Citation:

---

Envoyé par http://www.sqlite.org/about.html

Think of SQLite not as a replacement for Oracle but as a replacement for fopen()

---

selon les recommandations de l'éditeur :
sqlite est conçu pour supporter des bases jusqu'à 2 puissance 41 bytes (tebibytes)
mais il n'atteindra jamais ce nombre car aucun systeme ne peut supporter de
fichier aussi gros. Il peut néammoins aller jusqu'aux limites du disque.
Il est seulement conseillé de changer d'engine si les temps d'accès deviennent rédhibitoires et qu'on veut répliquer la base.

Pour une appli standalone, les benchmarks restent excellents

Si vous avez de bonnes infos de volumétrie, je suis hyper interressé !

Quant au sujet de l'article, je me sers peu des contraintes sur foreign keys. Quelqu'un a-t-il des exemples concrets ? (je suis sous sqlite ado.net)

Citation:

---

Envoyé par unBonGars

selon les recommandations de l'éditeur :
sqlite est conçu pour supporter des bases jusqu'à 2 puissance 41 bytes (tebibytes)
mais il n'atteindra jamais ce nombre car aucun systeme ne peut supporter de
fichier aussi gros. Il peut néammoins aller jusqu'aux limites du disque.
Il est seulement conseillé de changer d'engine si les temps d'accès deviennent rédhibitoires et qu'on veut répliquer la base.

Pour une appli standalone, les benchmarks restent excellents

Si vous avez de bonnes infos de volumétrie, je suis hyper interressé !

Quant au sujet de l'article, je me sers peu des contraintes sur foreign keys. Quelqu'un a-t-il des exemples concrets ? (je suis sous sqlite ado.net)

---

Je suis en train de créer un petit client P2P qui utilise SQLite.
J'utilise SQLite pour stocker les informations sur les fichiers partagés: chaque fichier est divisé en parties de 4,2Mio.
Sur un portable moyen (C2D 2,1 Ghz):
- L'insertion des parties d'un gros fichier (~10 Gio, donc à peu près 2 500 parties/enregistrements) se fait instantanément ;
- Les recherches avec 150 Gio de fichiers (donc un peu plus de 35 000 enregistrement), les recherches sont toujours très rapides, je ne saurais pas dire exactement comme ça, mais c'est instantané pour l'utilisateur.

J'utilise SQLite avec ADO.NET en C#, sour Mono et .NET, mais je n'utilise pas de Dataset ou les fonctionnalités avancées d'ADO.NET, qui sont plus gourmantes.

Pour les contraires de clé étrangères: http://www.sqlite.org/foreignkeys.html

Citation:

---

Que pensez-vous de cette nouveauté ?
Va-t-elle permettre un nouveau regain d'intérêt pour cette base de données ?

---

C'est une très grosse avancée, très attendue... mais je ne l'utiliserai pas dans mon travail de tous les jours.


Pour ma part, j'utilise tous les jours SQLite pour trier, tester et préparer des résultats issus d'un autre SGBD (Oracle).
(ou pour mettre au point des scripts à destination ce SGBD)

Par exemple, on me fourni des fichiers csv de plusieurs milliers, voir centaines de milliers de lignes... je dois rapidement fusionner les données, trouver des doublons ou des trous, formater des données et générer des tableaux sous Calc (équivalent de Excel).
Créer un format d'import de csv ne me prend que deux minutes, le lire et générer une table de 100.000 lignes indexées... cinq secondes !

Ensuite, les exports sont miraculeusement rapides. Les vues s'enchainent, puis les vues de vues... bref en moins de temps qu'il ne le faut pour l'écrire, une base complexe est créée et ... oubliée l'heure suivante.

SQLite est un couteau suisse que j'emmène toujours sur ma clé USB . Aussi utile qu'une fourchette pour avaler des tonnes de données. Pas la peine d'avoir un moteur SGBD avec une installation de plusieurs heures (jours) lorsque le besoin est de lire quelques fichiers, les fusionner et en sortir un document exploitable.

Prochaines avancées que j'attends de pied ferme : les fonctions mathématiques de base, les fonctions de traitement de caractères.

Ex: select sign(-5);
ou to_char(X'45') ou l'inverse de la fonction hex() ...

a+

Citation:

---

Envoyé par bigane

C'est une très grosse avancée, très attendue.
Prochaines avancées que j'attends de pied ferme : les fonctions mathématiques de base, les fonctions de traitement de caractères.

Ex: select sign(-5);
ou select to_char(X"45");

a+

---

+1
Sauf qu'avoir des contraintes plus complètes, comme pouvoir faire des sous requêtes ou mettre des fonctions en place de constantes dans les DEFAULT (style DEFAULT STRFTIME()), ca me semble plus prioritaire, car c'est déjà "virtuellement" implanté, il reste juste à s'arranger pour que le moteur puisse prendre en compte ce type de syntaxe.

Mais il y a clairement une carence dans les fonctions de base, je suis pas le seul a constater ça :ccool:.
Le problème, c'est que les créateurs veulent a tout prix que le binaire reste en dessous des 300Kio, et c'est vraiment dommage, car c'est a cause de ça que le nombre de fonctions est assez limité, alors que l'on peut les obtenir et qu'elles existent dans des libs supplémentaires officielles.

C'est en tous cas étonnant et agréable de voir qu'une si petite lib peut être aussi puissantes \o/.

Citation:

---

Envoyé par Rapha222

- L'insertion des parties d'un gros fichier (~10 Gio, donc à peu près 2 500 parties/enregistrements) se fait instantanément ;

---

Vrai, mais ça se dégrade très fortement si les volumes deviennent importants. En même temps c'est pas fait pour on dira.

Au fait, je ressorts un extrait d'un Interview de D. Richard Hipp (auteur de SQLite) :

Citation:

---

Les fonctionnalités qui pourraient apparaître dans les prochaines versions sont la recherche full-text, et la possibilité de réaliser des lectures et écritures incrémentales sur les BLOBs.

---

Miam !

Mise en oeuvre :
http://www.sqlite.org/cvstrac/wiki?p=FtsUsage

Exemples :
http://tuxce.selfip.org/informatique...ichiers-textes
http://blog.bjornoya.be/lab_stacks/2...-integral.html

Article de presse:
gnulinuxmag mai 2009


a+

Merci pour l'info :ccool:
j'étais en train de faire mon mcd pour une base sqlite destinée à une extension firefox et je pestais d'avance de tous les triggers que j'allais devoir écrire pour garder l'intégrité/contraintes des données ...
par contre, j'ai observé que la dernière dll inclue à FF 3.5.4 embarqué la version 3.6.16.0 de sqlite.
j'ai téléchargé le fichier sqlitedll-3_6_19.zip pour inclure à Firefox, me reste plus qu'a tester. Heu, j'avoue, je bidouille plus que je développe ...:oops:
A+

Désolé je me sers rarement des fonctions en cascade, les foreign keys se limitent à la gestion de l'index pour moi, je fais les checks d'intégrité depuis l'appli.
Concernant la volumétrie, je suis arrivé à 50 millions sans trop de problèmes.

Quand Richard Hipp dit que sqlite est plus dans la lignée fopen() que oracle, il veut dire que ce n'est pas une sgbd pour faire du client-serveur mais plutot pour régler une fois pour toutes la question des fichiers de données ou "document" d'une application standard (fichier/Ouvrir | Enregistrer ..)

C'est là que SQLite est génial. Si vous voulez faire du client serveur ou multiuser, ou réplication ou ..., vous serez plus heureux avec un autre sgbd.