Version 13 — Novembre 2012 — James
sudo pecl install pdo_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)
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.