0
Une nouvelle version mineure est sortie le 18 juin pour le moteur de base de données SQL SQLite.
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.
![[en]](../images/en.png)
SQLite (606 hits)-
Le changelog (238 hits)
-
La page de téléchargements (172 hits)
> Lire la suite (23 commentaires, moyenne: 1,6). [dépêche : 2652 caractères]
Vous avez demandé le commentaire #845669.
Run by 
Cette page a été générée par Templeet en 0.0809s (dont 0.0078 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Avec PHP5 ?
Sur le principe, l'intégration de SQLite à PHP5 a l'air extrêmement intéressante puisque sans installation, rapide et avec des sauvegardes simplissimes.
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 ?
Ben déjà c'est intéressant quand tu ne peux pas te permettre de faire tourner un serveur SQL ou quand tu as besoin de déplacer l'application et sa base.
[^]Re: Avec PHP5 ?
Autre contexte intéressant, que j'ai mis en pratique sur des logiciels classiques (application type CD-Rom, Borne, etc...) : ça m'a énormément amélioré les problèmes de stockage !!! Ca ne pèse rien du tout et tu as toutes les fonctions courantes d'un SQL !!! Et couplé à un ZMWS, tu peux faire tourner des sites en local sans aucune configuration.
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 ?
Il se trouve que pour mes besoins persos j'ai fait un petit projet avec SQLite, une sorte d'ampache mais à la sauce ajax ( téléchargeable ici pour ceux que ça intéresse : http://www.mychoonz.com ).
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 ?
Tu as pensé à appliquer ta fonction qui remplace les caractères accentués sur le terme de la recherche associé à un OR ? Du genre :
$sql = 'SELECT ... WHERE ARTISTE = "'.$nom.'" OR ARTISTE = "'.remplace_carac_accentue($nom).'"';
[^]Re: Avec PHP5 ?
Je ne comprend pas ce que ça peut apporter mais je passe sans doute à coté de quelque chose... une petite explication ?
La requête générée est la suivante :
(Chercher dans un seul champ change peu de choses coté performance.)
[^]Re: Avec PHP5 ?
euh... j'ai conscience aussi que "%" ça peut être couteux... mais quand même.
[^]Re: Avec PHP5 ?
Là, tu appliques ta fonction sur les champs de ta base, cette fonction est donc appelée autant de fois que de champs.
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 ?
certes... mais c'est bien l'effet recherché puisque je ne veux pas tenir compte des accents.
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 ?
C'est vrai que ça peut rapidement devenir lourd, mais toujours moins que d'appliquer la fonction sur *tous* les champs de ta base.
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 ?
Certes c'est moche... mais ne serait-ce pas plus rapide que ta première solution ? J'avoue que la comparaison m'interesse beaucoup. Si tu as le temps, tiens nous au courant là dessus. Mais peut-être qu'un SQLite-addict pourrait nous donner une jolie manière de faire optimisée.
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 ?
Ce serait sans doute plus rapide mais encore faut-il générer toutes les versions de la chaine à rechercher... ce qui peut vite être phénoménal !
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 ?
Pour ma culture personnelle, tu l'utilises comment la clause COLLATE pour ton exemple ?
[^]Re: Avec PHP5 ?
Tu peux créer une colonne supplémentaire, indexée si possible, qui stocke la version phonétique de ta clé. C'est une version épurée (normalisée) de la chaîne (retrait des accents, des lettres doublées, ch|sh|sch -> ch). Pour les détails je crois qu'un piti Google peut aider.
Lors de la recherche, tu épures la chaîne avant de la passer à la requête.
Et hop!
[^]Re: Avec PHP5 ?
Voir ici : http://aspell.net/metaphone/
[^]Re: Avec PHP5 ?
Pour avoir de nombreuses fois perdu beaucoup de données car j'avais oublié de sauvegarder ma base de donnée MySQL, je préfère maintenant pour tous mes développements local utiliser soit SQLite, soit directement des fichiers.
J'aime bien SQLite.
La Roue du Temps