Wiki utilisant MySQL ou des fichiers textes, ça change rien à la pérénité. L'essentiel du wiki étant le contenu des pages ! Dans MediaWiki par exemple, c'est un champ d'une table (en l'occurance, wiki_cur.cur_text de type « mediumtext », texte codé en UTF-8). L'intérêt de MySQL (ou autre SGBD) est que c'est plus optimisé que des accès à des fichiers textes standards (exemple : recherche plein texte, tri selon différents critères, etc.). Le désavantage est qu'il faut un serveur.
Pour rappel, les bases de donnée ont été inventées pour palier aux défauts des systèmes basés uniquement sur des fichiers ...
Pour moi, un wiki c'est plus que des documents : y'a la gestion des utilisateur, gestion de l'historique, recherche, ...
Faire des sauvegardes : pas de pb. MySQL permet de faire un dump, et d'ailleurs avec les tables au format InnoDB on peut avoir un dump alors qu'on est en train de modifier la base parallèlement. Un p'tit script bash avec sauvegarde de la base + sauvegarde des fichiers (images) et puis c'est tout.
[^] # Re: Résultats ?
Posté par Victor STINNER (site web personnel) . En réponse au journal Un wiki pas cher. Évalué à 1.
Pour rappel, les bases de donnée ont été inventées pour palier aux défauts des systèmes basés uniquement sur des fichiers ...
Pour moi, un wiki c'est plus que des documents : y'a la gestion des utilisateur, gestion de l'historique, recherche, ...
Faire des sauvegardes : pas de pb. MySQL permet de faire un dump, et d'ailleurs avec les tables au format InnoDB on peut avoir un dump alors qu'on est en train de modifier la base parallèlement. Un p'tit script bash avec sauvegarde de la base + sauvegarde des fichiers (images) et puis c'est tout.
Haypo