jeudi 24 juillet

Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

Articles précédents : Logiciel

[23] Subversion 1.4.4
[20] K3DSurf 0.6.2 : champion du calcul mathématique ?
[27] Des jeux Libres pour GNU/Linux
[16] Tiny ERP : des nouveautés
[46] Danger from the Deep : version 0.3.0 disponible
[31] Kitsune 2.0 : jeu de lettres et de chiffres
[10] Qt Jambi est enfin disponible
[20] Nexuiz 2.3
[7] Trophy : aidez un projet Libre
[40] Open Sound System de retour vers le libre

Liens connexes

SQLite (594 hits)
Le changelog (234 hits)
La page de téléchargements (167 hits)

Dépêche modérée par

Floxy

Dépêche éditée par

Logiciel : SQLite 3.4.0 est sorti

Posté par tuiu pol (Jabber id, ). Modéré le 26 juin 2007.

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.

SQLite (594 hits)
Le changelog (234 hits)
La page de téléchargements (167 hits)

> Lire la dépêche (23 commentaires, moyenne: 1,6).

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.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Avec PHP5 ?

Posté par Juvenal (page perso, ) le 26/06/2007 à 14:03. (lien). Évalué à 1.

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 ?

Posté par tuiu pol (Jabber id, ) le 26/06/2007 à 14:25. (lien). Évalué à 3.
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 ?
  
  Posté par alouali (page perso, ) le 26/06/2007 à 18:13. (lien). Évalué à 5.
  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 ?

Posté par choon () le 26/06/2007 à 19:55. (lien). Évalué à 2.
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 ?
  
  Posté par Juvenal (page perso, ) le 26/06/2007 à 20:35. (lien). Évalué à 1.
  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 ?
    
    Posté par choon () le 26/06/2007 à 20:49. (lien). Évalué à 1.
    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 :
    
    SELECT * FROM song WHERE noDiacritics(artist) like "%bjork%" OR noDiacritics(title) like "%bjork%" OR
    
    noDiacritics(album) like "%bjork%" OR genre like "%bjork%" ORDER BY stamp DESC LIMIT 0,20
    
    (Chercher dans un seul champ change peu de choses coté performance.)
    - [^]Re: Avec PHP5 ?
      
      Posté par choon () le 26/06/2007 à 20:51. (lien). Évalué à 1.
      euh... j'ai conscience aussi que "%" ça peut être couteux... mais quand même.
    - [^]Re: Avec PHP5 ?
      
      Posté par Juvenal (page perso, ) le 26/06/2007 à 21:10. (lien). Évalué à 2.
      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 ?
        
        Posté par choon () le 26/06/2007 à 21:27. (lien). Évalué à 1.
        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 ?
        
        Posté par Juvenal (page perso, ) le 26/06/2007 à 22:22. (lien). Évalué à 1.
        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 ?
        
        Posté par omnikron () le 26/06/2007 à 22:29. (lien). Évalué à 2.
        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 ?
        
        Posté par choon () le 27/06/2007 à 05:33. (lien). Évalué à 2.
        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:
        
        By default, when SQLite compares two text values, the result of the comparison is determined using memcmp(), regardless of the encoding of the string. SQLite v3 provides the ability for users to supply arbitrary comparison functions, known as user-defined collation sequences, to be used instead of memcmp().
        
        Mais je n'ai jamais trouvé comment procéder :-/
- [^]Re: Avec PHP5 ?
  
  Posté par skud () le 26/06/2007 à 22:23. (lien). Évalué à 1.
  Pour ma culture personnelle, tu l'utilises comment la clause COLLATE pour ton exemple ?
- [^]Re: Avec PHP5 ?
  
  Posté par VoixOff () le 27/06/2007 à 09:06. (lien). Évalué à 1.
  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 ?
    
    Posté par TeXitoi (Jabber id, page perso, ) le 27/06/2007 à 12:25. (lien). Évalué à 1.
    Voir ici : http://aspell.net/metaphone/

[^]Re: Avec PHP5 ?

Posté par Mildred (Jabber id, page perso, ) le 29/06/2007 à 12:59. (lien). Évalué à 2.
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

JOIN

Posté par garden () le 27/06/2007 à 02:07. (lien). Évalué à 2.

Quelqu'un a-t-il utilisé avec succès la fonction JOIN ?

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 (page perso, ) le 27/06/2007 à 06:12. (lien). Évalué à 1.
Question sans doute bête : as tu créé les bons index sur tes colonnes de jointure ?
- [^]Re: JOIN
  
  Posté par garden () le 27/06/2007 à 07:25. (lien). Évalué à 1.
  Ce n'est pas une question bête, c'est même sans doute la bonne question, puisqu'en effet je n'ai rien fait de tel ...
  
  Mais creer un index sur la colonne de jointure, dans les deux tables, je fais comment ?
  
  Merci d'avance !
  - [^]Re: JOIN
    
    Posté par chl (page perso, ) le 27/06/2007 à 10:56. (lien). Évalué à 2.
    http://www.sqlite.org/lang_createindex.html
    - [^]Re: JOIN
      
      Posté par alouali (page perso, ) le 27/06/2007 à 18:10. (lien). Évalué à 1.
      Merci d'avoir répondu à ma place !
      
      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 () le 28/06/2007 à 02:13. (lien). Évalué à 1.
        Un grand merci pour ces reponses. Je vais cependant verifier que la creation d'index corrige bien les defauts dont je me plaignais, puisqu'apres tout, vous ne me dites pas si vous utilisez la fonction JOIN avec SQlite de facon satisfaisante.
        
        A+, peut-etre
        
        [^]Re: JOIN
        
        Posté par alouali (page perso, ) le 28/06/2007 à 06:57. (lien). Évalué à 1.
        Pour répondre clairement, oui j'utilise du JOIN partout : car dans SGBDR, il y a le R de relationnel, qui signifie clairement "jointure". Pour simplifier, dans ces bases on remplace la redondance de champs et d'informations par des jointures et tables de jointures, c'est donc un minimum que les JOIN soient performants !
        
        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é).

Revenir en haut de page

Articles précédents : Logiciel

Liens connexes

Dépêche modérée par

Dépêche éditée par

Logiciel : SQLite 3.4.0 est sorti

Avec PHP5 ?

[^]Re: Avec PHP5 ?

[^]Re: Avec PHP5 ?

[^]Re: Avec PHP5 ?

[^]Re: Avec PHP5 ?

[^]Re: Avec PHP5 ?

[^]Re: Avec PHP5 ?

[^]Re: Avec PHP5 ?

[^]Re: Avec PHP5 ?

[^]Re: Avec PHP5 ?

[^]Re: Avec PHP5 ?

[^]Re: Avec PHP5 ?

[^]Re: Avec PHP5 ?

[^]Re: Avec PHP5 ?

[^]Re: Avec PHP5 ?

[^]Re: Avec PHP5 ?

JOIN

[^]Re: JOIN

[^]Re: JOIN

[^]Re: JOIN

[^]Re: JOIN

[^]Re: JOIN

[^]Re: JOIN