Carnet Wiki

sqlite

Version 12 — November 2012 — goetsu

Notes et trucs autour de sqlite pour spip

spip , à compléter , à structurer}

  1. la sauvegarde spip 3 se fait désormais dans un format sqlite, que la base de donnée soit au format MYSQL ou SQLITE
  2. sqlite est en général intégré en standard aux installations de php5... mais exceptionnellement ce n’est pas le cas.
  3. un équivalent léger de phpmyadmin pour sqlite, utilisable en local uniquement (mamp, easyphp etc) est un plugin de firefox: sqlite manager et codev, un plugin pour le navigateur chrome
  4. les écritures dans la base de donnée sont très coûteuses avec sqlite : 100ms par opération constate mm.
  5. si on gère son serveur sous Ubuntu, il faut installer sqlite3 et pas sqlite ! ça se fait avec :
    sudo pecl install pdo_sqlite
  6. il n’est en général PAS possible de migrer un spip de mysql vers sqlite, ou de sqlite vers mysql, en passant par le fichier de sauvegarde (sauf si vous êtes un expert en BDD et structure data spip, et prêt à bidouiller pointu dans les bases). C’est toutefois possible parfois, en apparence au moins, mais par exemple dans le sens SQLITE vers MYSQL, on perd des infos de structures de base comme l’autoincrement.
    ça se fait avec :
    <
    code>sudo pecl install pdo_sqlite</code >
    -# certaines extensions de mysql ne sont pas disponible pour sqlite : notamment geométrie (pour GIS), fullsearch
  7. sur une mutualisation SPIP, les 2 formats de données ne cohabitent pas (sur des sites différents) par défaut. Selon un témoignage, il est toutefois possible de le faire en choisissant un des 2 dans mes_options.

Limites et intérêts de SQLITE

-  sqlite est bien pour développer en local un site temporaire et pour en faire les tests. Notamment parce que toute la base de donnée est en fichier sous le répertoire config.

-  en ligne sqlite est bien sur un hébergement dédié

-  sur un hébergement mutualisé, sqlite peut donc aller moins vite que mysql, selon la configuration du serveur, en raison des accès disques : sur un mutualisés, les accès aux fichiers sont parfois lents car déportés sur le réseau, or avec sqlite, la base de donnée est dans un fichier.

Le principal intérêt de sqlite est que la base est dans un fichier situé dans /config. Du coup, le site est “portable” : il suffit de copier le répertoire pour disposer d’un backup de tout le site (fichiers + base)

Passages de SQLITE à MYSQL ou réciproquement

Etant donné que tant les spip fonctionnant avec SQLite que ceux fonctionnant avec MYSQL font leurs sauvegardes dans un dump au format sqlite, on pourrait penser qu’il est possible de facilement changer le format de base de donnée en l’exportant/important via ce dump, après avoir changé de format. Ce n’est pas exactement le cas.

Une raison est historique : SPIP ne fonctionnant initialement que sous mySQL les structures sont décrites dans le formalisme correspondant, et le connecteur SQLite de SPIP se débrouille pour transposer.
A contrario, le connecteur mySQL de SPIP ne sait pas prendre une structure ecrite dans un autre formalisme que le sien.

L’autre raison tient au fait que la structure SQLite est moins riche que la structure mySQL.

Le passage de SQLite vers MYSQL (via un dump SQLite) n’est en général PAS possible

Il est difficile de deviner certaines informations de structure qui ne sont plus présentes dans SQLite pour recréer une table mySQL à partir de la structure SQLite. On perd des infos de structures de base comme l’auto-increment.

Le passage de mySQL vers SQLite (via dump SQLite) est par contre possible

On peut déduire la première de la seconde sans perte d’information.

_