sqlite

Voir aussi Accéder aux bases SQLite

Notes autour de SPIP & SQLite

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 normalement intégré par défaut à PHP 5... mais ce n’est pas toujours le cas.
3. les écritures dans la base de donnée sont très coûteuses avec sqlite : 100ms par opération constate mm « très couteuses » ? source ? donner une valeur sans comparaison n’a aucun sens...

Intérêts et limites de SQLite

Installer un SPIP avec SQLite est immédiat : pas besoin de créer une base dans un autre outil, pas besoin de login ni de mot de passe. Cela simplifie l’expérience de la première installation.

La base de données Sqlite est dans un fichier (rangé dans config/bases). Du coup, il est facile de copier ou transporter tout son site : il suffit de copier le répertoire de SPIP pour disposer d’un backup complet de tout le site (fichiers + base) que l’on peut réinstaller autre part.

Sur un hébergement mutualisé, SQLite peut être moins rapide 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. Raisonnement erroné : sur un hébergement mutualisé mySQL est aussi sur un autre serveur et les accès se font par réseau comme pour SQLite. Cela ne change rien en relatif mySQL vs SQLite que l’on soit sur un dédié ou sur un mutualisé

Passages de SQLite à mySQL ou réciproquement

Le passage de mySQL vers SQLite (via dump SQLite) est simple et sans risque

Si vous avez un site sous mySQL il suffit de faire une sauvegarde depuis le site et de la réimporter dans un site installé avec SQLite. Le passage dans ce sens est généralement très bien supporté et ne pose pas de problèmes.

Le passage de SQLite à mySQL (via un dump SQLite) est problématique

La structure d’une base SQLite est plus pauvre que celle d’une base mySQL et il est difficile de recréer la structure de la base mySQL à partir de celle de SQLite sans risque de bugs ultérieurs.

En attendant que le passage de mySQL à SQLite soit automatiquement pris en charge, il existe une procédure manuelle.

Procédure manuelle pour passer sa base de SQLite à mySQL :

• Sur le site 1 installé avec SQLite faire une sauvegarde dans tmp/dump/dump1.sqlite
• Installer un site 2 avec mySQL avec tout les mêmes plugins (mêmes tables dans la base de donnée)
• Sur ce site 2 installé avec mySQL faire une sauvegarde dans tmp/dump/dump2.sqlite
• Exporter la table spip_meta du dump2.sqlite dans un fichier :
  echo ".dump spip_meta" | sqlite3 dump2.sqlite > metadump2.txt
• Supprimer la meta de structure dans dump1.sqlite :
  echo "delete from spip_meta where nom='dump_structure_temp';" | sqlite3 dump1.sqlite
• Mettre à jour la table spip_meta dans dump1.sqlite :
  sqlite3 dump1.sqlite < metadump2.txt
• Importer le dump1.sqlite dans le site 2 sous mySQL depuis l’interface SPIP.

Cette procédure repose sur le fait que les bases du site 1 et du site 2 ont les mêmes tables avec les mêmes champs. Il faut donc faire bien attention à avoir tous les mêmes plugins installés.

Administration

Une gestionnaire de base de données en ligne ? http://www.adminer.org

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

Si on gère son serveur sous Ubuntu, il faut installer sqlite3 et pas sqlite ! ça se fait avec :
sudo pecl install pdo_sqlite

Cas particuliers

1. certaines extensions de mysql ne sont pas disponible pour sqlite : notamment geométrie (pour GIS), fullsearch
2. 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.