Q: Quel est le site PmWiki comportant le plus grand nombre de pages?
Pm: Bien sûr il n'y a aucune limite théorique au nombre de pages de part la façon avec lesquelles PmWiki les organise.
Les limites pratiques sont le nombre de fichiers maximum qui peuvent être gérés au sein d'un unique répertoire (wiki.d), et le temps de recherche nécessaire pour parcourir toutes les pages. Comme références, le SciTechWiki (http://www.sci.tamucc.edu/wiki(sitios aprobados)) posséde actuellement 1649 pages et le TAMUCC Wiki (http://www.tamucc.edu/wiki(sitios aprobados)) plus de 4500, et tous deux semblent fonctionner sans aucun problème; même les recherches ne semblent pas prendre un temps déraisonnable. Ces deux wikis fonctionnent sous environnement Red Hat Linux. Je sais que sous RH Linux, j'ai des répertoires contenant plus de 5000 fichiers sans aucune difficulté majeure (dossier d'archive de mailing liste), aussi je ne crois pas que le système (OS) pose une barrière à PmWiki, du moins sur ce point.
Cependant, j'ai un peu réfléchi à ces problèmes en concevant PmWiki et voici ce que j'ai décidé pour le moment. D'abord, dans la mesure où les limitations de répertoires sont possibles, j'ai mis en place les variables $PageFileFmt, $WikiDir, et $WikiLibDirs de sorte qu'un administrateur puisse organiser les fichiers dans une structure de dossier alternative autre que juste "wiki.d/Group.Pagename". Par exemple, $PageFileFmt pourrait être changé en '$Group/$Title_' ou '$Group/$PageName' et les fichiers seraient stockés en tant que "wiki.d/Group/Pagename" ou "wiki.d/Group/Group.Pagename", ce qui réduirait le nombre global de fichiers dans n'importe lequel des dossiers. Il faudrait toujours créer les dossiers pour les groupes, mais ceci n'est pas un gros problème. Et même si cette approche ne fragmente pas suffisamment les choses (par ex., un groupe avec des milliers de pages) il y a toujours d'autres options--avec une ou deux petites extensions les fichiers peuvent être organisés dans des dossiers basés sur sur la(les) première(s) lettre(s) du titre, comme dans "wiki.d/P/Group.Pagename" et "wiki.d/W/Group.WikiWord". Ce qui répartirait la charge sur encore plus de répertoires également.
Et, bien sûr, je pourrais toujours regarder du côté des bases de données relationnelles ou d'autres projets d'indexation s'il devenait nécessaire de faire ainsi. Cependant j'aime la simplicité, et c'est certainement l'un de secteurs où j'ai choisi d'éviter les fonctionnalités gratuites; c.-à-d., opter pour une approche simple maintenant et se lancer dans une implémentation complexe seulement quand un besoin réellement démontré se fait sentir, auquel cas les vrais paramètres du problème sont mieux connus. Je suis également plutôt tranquille avec le fait qui si nous devons changer le modèle principal de stockage à un certain moment,il sera facile de créer une voie de migration du schéma existant vers un neuf.
Note : Main/SearchWiki devient de plus en plus sophistiqué à mesure que PmWiki croît. Des fonctions de recherche avancées ont été ajoutés à PmWiki. Si ces dispositifs de recherche inclus dans PmWiki ne sont pas suffisants, il y a déjà quelques excellents systèmes d'indexation et de recherche, et il est beaucoup plus efficace de se servir de ces systèmes existants plutôt que d'essayer de les reproduire dans PmWiki.
<< Fermes Wiki | Index doc admin | Désinstallation de PmWiki? >>
Traduction de ? - Page originale sur PmWiki:PmWikiFr.TailleLimite
.
Page originale sur PmWikiFr.TailleLimite - Backlinks
Dernières modifications:
PmWikiFr.TailleLimite: 2005-10