Discussion :

[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