Un Spip - 100 minisites

Salut la liste

J'aurais aimé savoir s'il vous semblait plausible de créer un site
père (partiellement géré par Spip) et une centaine de "minisites",
dont chacun se baserait sur un ensemble de gabarits similaires (seuls
les contenus seraient différentsn donc tous gérés par Spip).

La question qui se pose alors est de savoir :

- s'il vaut mieux mutualiser chaque minisite comme un site à part
entière (soit la mutualisation classique), sachant que TOUS seront
hébergés sur une même base Mysql (trop coûteux d'avoir 100+ bases...),
soit environ 35 tables / sites... 3500 tables, est-ce trop pour un
seul noyau Spip, ou autre problème ?
(sachant qu'il est simple de créer un site supplémentaire une fois
l'arbo crée => un dossier mutualisé, un nouveau site, etc., et on a un
Back office différent par site)

- s'il vaut mieux partir sur un système de rubricage, avec un secteur
"minisites", et après, une rubrique pour chaque minisites, et
hiérarchie classique pour la suite de la gestion des mini sites... du
coup, un seul back office, un seul jeu de table... visiblement plus
lours donc, mais pour Spip, je ne peux pas m'avancer.

Merci de vos nombreux avis =)

--
JR

Cette question concerne moins SPIP
que le serveur SQL qu'il y a derrière.
Dans la version mutualisée la partie PHP
s'exécutera sur de plus peittes données,
mais demandera plus de boulot au serveur SQL.
A priori je lui ferai plus confinace qu'à PHP pour foncer.

L'autre aspect est l'administration que ça représente:
si tu délègues chaque site à qq, le plus simple est la
première solution, sinon taper un mot de passe 1000 fois jour,
ça craint.

Committo, Ergo Sum.

Merci pour la réponse =)

Visiblement, on partirait bien sur la premier solution, on verra ce
que ça donne au niveau perfs, mais vaut mieux interagir sur des
petites tables plutôt qu'une seule énorme =))

--
JR