Discussion :

[Emmanuel Lecoester]

SQLite Release 3.6.19 On 2009 Oct 14 (3.6.19)

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 ?

[_skip]

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é.

[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

[Rapha222]

ç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

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

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, ...

[sidev]

(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.

[Rapha222]

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

[Invité]

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.

[Rapha222]

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:

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

[robert_trudel]

ç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

lequel?

mysql, oracle, db2?

[Rapha222]

lequel?

mysql, oracle, db2?

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

[Rapha222]

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 ...

[bigane]

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+

[Rapha222]

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 .
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/.

[Invité]

j'ai lu ce topic avec intéret, je vois que je ne suis pas le seul à avair adopté sqlite. Auparavant , j'utilisais Access qui fait bien d'autres choses que de stocker des données. SQLite donne un nouveau souffle à ceux qui ont acquis un savoir faire sous access avec une architecture voisine et une tenue en charge nettement meilleure. Bien sûr la comparaison s'arrète là , sqlite n'est pas un outil bureautique, ni même un sgbd mais plutôt un "datafile replacement" comme le dit son papa R. Hipp.

Selon la presse il est le plus installé au monde avec un portfolio impressionnant, il est aussi l'organe vital de Symbian et utilisé dans l'os de l'IPhone. Ca en fait un outil assez unique en son genre , le comparer à d'autres est une erreur même si la portabilité vers un SGBDR est bonne merci SQL, ça se complique sérieusement si on regarde l'aspect connexion. Si un programme est déjà très volumineux, la stratégie de connexion sera sans doute à refaire pour passer de SQLite à autre chose.

Pour le thème de ce topic, La gestion des clés étrangères, c'est le delete cascade, ou au moins la remontée d'un message en cas de destruction de ligne parente. Ca pose un tas de questions connexes : comment remonter les erreur de l'engine, faut il les récupérer dans une exception, les retourner à l'utilisateur brutes de fonderie ?
Sous ado.net sqlite retourne des mlessages laconiques mais très clairs et sous débugger , ça aide beaucoup. Mais l'utilisateur du programme n'a pas de débugger (?) donc il faut bien savoir ce qu'on fait des messages remontés. Bref, je ne me servirai pas tout de suite de cette fonction mais je salue son existence et quand j'aurai redessiné mes schemas pour poser les contraintes ad hoc, je verrai bien ce que je peux faire des messages correspondants. Il est clair qu'on s'en sortait très bien sans jusqu'ici. Mais celui qui aura réellement testé les contraintes FK ou celui qui rame avec des triggers pour faire de même saura sans doute mieux de quoi il retourne pour autant qu'il ait le courage de remplacer ses triggers par un redesign du schema : gros travail à priori..

[Rapha222]

j'ai lu ce topic avec intéret, je vois que je ne suis pas le seul à avair adopté sqlite. Auparavant , j'utilisais Access qui fait bien d'autres choses que de stocker des données. SQLite donne un nouveau souffle à ceux qui ont acquis un savoir faire sous access avec une architecture voisine et une tenue en charge nettement meilleure. Bien sûr la comparaison s'arrète là , sqlite n'est pas un outil bureautique, ni même un sgbd mais plutôt un "datafile replacement" comme le dit son papa R. Hipp.

Selon la presse il est le plus installé au monde avec un portfolio impressionnant, il est aussi l'organe vital de Symbian et utilisé dans l'os de l'IPhone. Ca en fait un outil assez unique en son genre , le comparer à d'autres est une erreur même si la portabilité vers un SGBDR est bonne merci SQL, ça se complique sérieusement si on regarde l'aspect connexion. Si un programme est déjà très volumineux, la stratégie de connexion sera sans doute à refaire pour passer de SQLite à autre chose.

Pour le thème de ce topic, La gestion des clés étrangères, c'est le delete cascade, ou au moins la remontée d'un message en cas de destruction de ligne parente. Ca pose un tas de questions connexes : comment remonter les erreur de l'engine, faut il les récupérer dans une exception, les retourner à l'utilisateur brutes de fonderie ?
Sous ado.net sqlite retourne des mlessages laconiques mais très clairs et sous débugger , ça aide beaucoup. Mais l'utilisateur du programme n'a pas de débugger (?) donc il faut bien savoir ce qu'on fait des messages remontés. Bref, je ne me servirai pas tout de suite de cette fonction mais je salue son existence et quand j'aurai redessiné mes schemas pour poser les contraintes ad hoc, je verrai bien ce que je peux faire des messages correspondants. Il est clair qu'on s'en sortait très bien sans jusqu'ici. Mais celui qui aura réellement testé les contraintes FK ou celui qui rame avec des triggers pour faire de même saura sans doute mieux de quoi il retourne pour autant qu'il ait le courage de remplacer ses triggers par un redesign du schema : gros travail à priori..

Les erreurs de sqlite, au niveau des triggers en tout cas, sont déclenchées par la fonction RAISE(). Celles-ci peuvent êtres capturées par la clause ON CONFLICT directement dans les requêtes.
SQLite retourne également un code d'exécution qui permet au programme qui exécute une commande de savoir si celle-ci s'est bien réalisée.

Avant, on avait des générateur de triggers d'intégrité et les déclarations des clés étrangères étaient ignorées par SQLite. J'utilisais les triggers, mais je laissais les définitions des clés étrangères dans la déclaration de la table. Ainsi, maintenant, il me suffit à peu de chose près de supprimer les triggers et d'activer la gestion de l'intégrité référentielle .

Un truc un peu dommage tout de même : je suis en première année en informatique, et le cours de l'année passée se basait sur Access mais les professeurs ont décidés de passer cette année à MySQL. C'est vraiment dommage, car SQLite à des tas d'avantages dans un cadre d'apprentissage par rapport à MySQL :

• Pas d'installation, l'élève à juste à copier/coller la .dll, c'est un avantage non négligeable ;
• SQLite est assez complet et fait tout comme les grands pour pas mal de choses, puisqu'il est transactionnel, qu'il supporte les triggers, les vues, les contraintes et maintenant l'intégrité référentielle ;
• la syntaxe de SQLite est vraiment fort respectueuse de la norme SQL:92, et le parseur est vraiment très puissant (il m'est déjà arrivé d'avoir du SQL avec des sous requêtes à plusieurs niveaux dans une vue que SQLite acceptait mais que MySQL refusait) ;
• c'est l'occasion de voir un autre paradigme : l'année prochaine nous travaillerons sur Oracle et connaitre un autre paradigme que le système client-serveur est tout de même un avantage sympathique, surtout que nous risquons fortement d'utiliser un jour SQLite à nouveau alors que MySQL, c'est moins probable ;
• SQLite est programmable directement dans le langage de l'API (création de fonction, de tables virtuelles, ...). Ca évite d'avoir à apprendre un nouveau langage et ça permet de mieux comprendre le fonctionnement interne d'un SGBDR ;
• pas besoin d'entrer dans la gestion des droits d'accès (ils sont déterminés par le système de fichiers avec SQLite) ni des types de stockage (SQLite a un typage dynamique) tout de suite ;
• ...

Enfin, c'est mon avis. Mais je vois pas mal d'écoles commencer à utiliser MySQL pour l'apprentissage du SQL alors que, pour moi, SQLite serait beaucoup mieux adapté. J'ai demandé à certains professeurs, en fait, beaucoup pensent que SQLite est vraiment un SGBDR ultra-simplifié et que ses fonctionnalités n'arrivent pas au niveau de MySQL, mais ce n'est pas le cas.

[Invité]

... je vois pas mal d'écoles commencer à utiliser MySQL pour l'apprentissage du SQL alors que, pour moi, SQLite serait beaucoup mieux adapté. J'ai demandé à certains professeurs, en fait, beaucoup pensent que SQLite est vraiment un SGBDR ultra-simplifié et que ses fonctionnalités n'arrivent pas au niveau de MySQL, mais ce n'est pas le cas.

je ne pense pas qu'on puisse mettre SQLite sur une échelle composée de SGBDR. Si le but du cours est d'apporter un savoir faire sur les grands réseaux, Oracle MSSS PostGre mySql sont incontournables.

SQLite apporte le sql dans une partie du programme où il n'y avait rien avant. Mais en accès partagé , il est encore pire qu'access !!! C'est le programme génial qui permet de faire des applis pointues mais pas du SGBDR à proprement parler. Au moins Access possède une interface odbc qui permet de se passer completement de son data engine, Sqlite n'est qu'un data engine tout nu, avec des benchmarks à couper le souffle mais rien ne le relie aux autres SGBD. Le comparer est une erreur de syntaxe !

Bonne continuation