Notes et trucs autour de sqlite pour spip, à compléter, à structurer
- la sauvegarde spip 3 se fait désormais dans un format sqlite, que la base de donnée soit au format MYSQL MYSQL(attention a un risque en creation-restauration ) ou SQLITE
- sqlite est en général intégré en standard aux installations de à php5... mais exceptionnellement ce n’est pas le cas.
mais parfois pas.
-# un équivalent léger de phpmyadmin pour sqlite, utilisable en local uniquement (mamp, easyphp etc) est être un plugin de firefox : sqlite manager et [codev, un plugin pour le navigateur chrome->http://codev.it /]
_ -# les écritures dans la base de donnée sont très coûteuses avec sqlite : 100ms par opération constate mm. - si on gère son serveur sous Ubuntu, il faut installer sqlite3 et pas sqlite ! ça se fait avec :
sudo pecl install pdo_sqlite - il n’est 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 ).
bases) [serait peut" id="nh1">1].
-# certaines extensions de mysql ne sont pas disponible pour sqlite : notamment geométrie (pour GIS), fullsearch - jusqu’à plus ample informé, sur une mutualisation SPIP, les 2 formats de données ne cohabitent pas ( sur des sites différents ). .
Limites et intérêts de SQLITE
- sqlite est bien pour développer en local un site temporaire et pour en faire les tests
- en ligne sqlite est bien sur un dédié
- sur un mutu sqlite peut aller moins vite que mysql, selon la configuration du serveur (en raison des accès disques)
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)
_