Cette version a été appelée 3.4.0 à la place de 3.3.18 pour attirer l'attention sur les possibles problèmes d'incompatibilités qui peuvent découler des ajouts effectués. En effet, cette version ajoute des limites explicites sur les tailles et les quantités des objets manipulés par SQLite. Les nouvelles limites peuvent causer des problèmes de compatibilité avec les applications existantes qui utilisent exagérément les larges strings, BLOBs, tables ou les rapports SQL. Ces nouvelles limites peuvent être augmentées lors de la phase de compilation. Au menu de cette version (tiré du changelog) :
- Ajout des limites explicites sur la taille et la quantité des choses que SQLite peut manipuler ;
- Ajout du support pour les I/O incrémental des BLOB ;
- Ajout de l'API zeroblob et de la fonction SQL zeroblob ;
- Ajout du support pour les vacuum incrémentaux ;
- Ajout de l'option de compilation SQLITE_MIXED_ENDIAN_64BIT_FLOAT pour le support des processeurs ARM7 (gestion de l'endianness) ;
- Suppression de toutes les instances de sprintf() et strcopy() dans le coeur de la bibliothèque ;
- Ajout du support des ICU dans les extensions de recherches textuelles ;
- Correction du bug qui pouvait mener à une corruption de base si une erreur SQLITE_BUSY arrivait lors d'une transaction et que cette transaction était, ensuite, "commitée" ;
- Correction du bug qui pouvait mener à une corruption de base si le mode autovacuum était activé et qu'une erreur de malloc() suivait un état CREATE TABLE ou un état CREATE INDEX qui, lui-même, suivait un dépassement de cache pendant une transaction ;
- Correction de la fonction REPLACE() qui retourne NULL si le second argument est une chaine vide ;
- Internationalisation de la fonction TRIM() ;
- utilisation de memmove() au lieu de memcpy() lorsqu'il y a un mouvement entre des régions de mémoire qui peuvent se recouvrir ;
- etc.
Pour rappel, SQLite est une petite bibliothèque écrite en C qui propose un moteur de base de données SQL et implémentant en grande partie le standard SQL92 et les propriétés ACID. Contrairement aux serveurs de bases de données comme MySQL ou PostgreSQL, sa particularité est de ne pas reproduire le schéma habituel client/serveur mais d'être intégré directement aux programmes en utilisant des fichiers de bases de données.
SQLite est dans le domaine public. Des binaires sont disponibles dans la page de téléchargement pour GNU/Linux et Microsoft Windows.
Aller plus loin
- SQLite (16 clics)
- Le changelog (2 clics)
- La page de téléchargements (9 clics)
# Avec PHP5 ?
Posté par Juvenal . Évalué à 1.
Mais personnellement, je n'ai pas encore franchi le pas. J'utilise MySQL, non par véritable choix, mais parce que c'est la base la plus répandue chez les hébergeurs.
Maintenant que PHP5 est bien diffusé, je voudrai avoir des avis.
Quelle performance ? quelle maturité ? dans quel contexte est-ce (ou n'est-ce pas) intéressant ? les interfaces (ex. SQLiteManager) sont-elles efficaces ?
[^] # Re: Avec PHP5 ?
Posté par tuiu pol . Évalué à 3.
[^] # Re: Avec PHP5 ?
Posté par alouali (site web personnel) . Évalué à 5.
Mes programmes sont devenus plus simples, plus lisibles, plus performants (indexation des données, non redondance, requêtes compréhensibles, jointures, plus besoin des boucles indexées calculatoires pour les agrégations type sum, count, max, etc.). Jusqu'à SQLite, j'hésitais toujours entre stocker mes données dans un format texte (pas performant quand beaucoup d'enregistrements et de champs) ou un format binaire (jamais aussi optimisé qu'il faudrait : souvent un seul tri, un seul index). Sans compter le petit utilitaire SQLite en ligne de commande pour contrôler n'importe où mes bases !
Je sais on dirait la pub "avant j'avais l'air moche, maintenant j'ai l'air wick", mais je suis franchement enthousiaste. Pour moi, ce que fait SQLite en 300 petits kilos octets est un miracle, et je tire mon chapeau au développeur. De toute ma longue vie de développeur ça a surement été l'outil le plus génial qu'il m'ai été donné de rencontrer.
[^] # Re: Avec PHP5 ?
Posté par choon . Évalué à 2.
Au début SQLite est vraiment trés séduisant, les applications deviennent mobiles, les sauvegardes sont simplifiées,les outils comme SQLite browser sont trés pratiques, c'est vraiment le pied de ne pas se cogner l'installation de mysql, d'automatiser la création des tables, etc...
Maintenant sur les performances il faut mettre un bémol. Le site présente SQLite comme plus rapide que MySQL, benchmark à l'appui, mais ça ne veut pas dire grand chose dans un cas réel, notamment parce que SQLite est trés loin d'offrir autant de fonctionnalités que MySQL (ou d'autres). Le fait que l'on puisse importer les fonctions PHP dans SQLite permet de pallier certaines lacunes mais au prix d'une perte de performance.
Par exemple, je veux chercher dans mon appli tous les morceaux de musique dont l'interprête est ou contient "björk". Je ne veux pas que les accents soit pris en compte dans ma requête, l'utilisateur doit pouvoir taper "Bjork" comme "Björk"... comment je fais? A moins que je sois passé à coté de quelque chose (dans ce cas merci de me guider, ça m'enlèveras une épine du pied), la seule solution que j'ai trouvé (vu qu'apparemment un COLLATE ne marche pas), c'est d'importer une fonction PHP qui remplace les caractères accentués par leur équivalent ascii... ça marche, aucun soucis, mais... sur 15000 rangées c'est super lent (enfin super lent... 3 ou 4 secondes quoi!).
La même requête avec MySQL et la collation adéquate c'est immédiat... (je suis preneur de soluces pour améliorer les perfs avec sqlite si des super cracks en php/sqlite lisent ceci).
Voilà, tout ça pour dire que oui c'est chouette mais que non ça ne fait toujours pas le café :-)
Ceci dit il y a tout un tas d'occasion ou SQLite peut-être super pratique et je n'hésiterais pas à l'utiliser à nouveau, sur des petits CMS ou des blogs par exemple.
[^] # Re: Avec PHP5 ?
Posté par Juvenal . Évalué à 1.
$sql = 'SELECT ... WHERE ARTISTE = "'.$nom.'" OR ARTISTE = "'.remplace_carac_accentue($nom).'"';
[^] # Re: Avec PHP5 ?
Posté par choon . Évalué à 1.
La requête générée est la suivante :
(Chercher dans un seul champ change peu de choses coté performance.)
[^] # Re: Avec PHP5 ?
Posté par choon . Évalué à 1.
[^] # Re: Avec PHP5 ?
Posté par Juvenal . Évalué à 2.
Alors que si tu appliques ta fonction sur le terme de la recherche, elle n'est exécutée qu'une seule fois.
[^] # Re: Avec PHP5 ?
Posté par choon . Évalué à 1.
Je m'explique... admettons qu'un utilisateur veuille trouver "ségolène" dans la base. Dans la base on peut avoir:
- segolene
- ségolene
- segolène
- ségolène
ou même plus de possibilités si c'est mal orthographié (ségoléne, sêgolène, etc...)
Je devrais faire ça? -> SELECT * FROM machin WHERE truc LIKE 'segolene' OR truc='ségolene' OR truc LIKE 'segolène' OR truc LIKE 'ségolène' OR.... etc.
:-(
[^] # Re: Avec PHP5 ?
Posté par Juvenal . Évalué à 1.
Ce qui serait le plus rapide, mais qui resterait "malpropre", c'est de créer une colonne où tu enregistrerais le titre sans accent...
C'est tout de même bizarre que rien ne soit prévu pour ça. :/
[^] # Re: Avec PHP5 ?
Posté par omnikron . Évalué à 2.
Je pense que l'avantage de "LIKE 'segolene' OR truc='ségolene' OR truc LIKE 'segolène' OR truc LIKE 'ségolène' OR...." est que c'est avec PHP que tu va générer la liste des "OR" de ta requête. Et je pense que c'est plutôt à PHP de faire cela qu'à SQLite.
[^] # Re: Avec PHP5 ?
Posté par choon . Évalué à 2.
Avoir une version sans accents de chaque colonne me parait une bonne idée... on garde de bonnes performances et on est pas obligé de faire des requêtes alambiquées. Reste que dans mon cas ça double pratiquement la taille de la base... pas grave sur quelques dizaines de méga-octets mais bon...
Une collation insensible aux accents serait évidemment le top. Le manuel dit que l'on peut avoir des collations définies par l'utilisateur:
Mais je n'ai jamais trouvé comment procéder :-/
[^] # Re: Avec PHP5 ?
Posté par mxt . Évalué à 1.
[^] # Re: Avec PHP5 ?
Posté par VoixOff . Évalué à 1.
Lors de la recherche, tu épures la chaîne avant de la passer à la requête.
Et hop!
[^] # Re: Avec PHP5 ?
Posté par TeXitoi (site web personnel) . Évalué à 1.
[^] # Re: Avec PHP5 ?
Posté par Mildred (site web personnel) . Évalué à 2.
J'aime bien SQLite.
# JOIN
Posté par garden . Évalué à 2.
Dans mon cas, SQlite se ralentit a l'extrême, et me multiplie les fiches à mesure qu'elles sont plus abondantes.
SELECT # FROM table1 JOIN table2 ON (table1.commonfield=table2.commonfield) WHERE # LIKE '%#%'
Je m'y prend mal ??
[^] # Re: JOIN
Posté par alouali (site web personnel) . Évalué à 1.
[^] # Re: JOIN
Posté par garden . Évalué à 1.
Mais creer un index sur la colonne de jointure, dans les deux tables, je fais comment ?
Merci d'avance !
[^] # Re: JOIN
Posté par chl (site web personnel) . Évalué à 2.
[^] # Re: JOIN
Posté par alouali (site web personnel) . Évalué à 1.
Les performances des SGBD sont grandement dépendantes du fait qu'on crée des index sur les champs les plus utilisés (notamment les clés, identifiants uniques), certains champs de recherche, et les champs de jointure (qui sont souvent des clés, si la base a été créée "proprement" avec le principe de base n°1 : "AUCUNE RENDONDANCE DE DONNEE").
On y perd un peu en espace, mais on y gagne grandement en performances !
[^] # Re: JOIN
Posté par garden . Évalué à 1.
A+, peut-etre
[^] # Re: JOIN
Posté par alouali (site web personnel) . Évalué à 1.
A ce propos, si tu utilises souvent certains JOIN, je t'invite à regarder la notion de VIEW : ça te permet de faire des sortes de "raccourcis" sur tes jointures les plus courantes, ce qui rends tes requêtes et ton code à la fois plus court et plus compréhensible. Et il peut être utile aussi de comprendre et maîtriser les différences entre INNER, OUTER, LEFT et RIGHT JOIN.
SQL est un langage de haut niveau, il est bon de lui déléguer tout ce qu'il peut faire et tout ce qui peut décharger ton code.
Sur le Web (Google est ton ami) tu trouveras plein d'articles sur les SGBDR, sur SQL, et comment utiliser les JOIN correctement ((tu trouveras même des articles qui expliquent le fonctionnement interne du JOIN de SQLite et il comment il est déjà optimisé).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.