Bonjour,
Normalement, on n'utilise qu'une seule base quelque soit le nombre de portails. Tu peux toujours faire ce que tu veux dans tes modules, mais du coup il ne seraient plus "standard". Si tu regarde un peu le code des différents modules "standard", les tables contiennent toujours une colonne PortalID pour identifier le portail en question. En fait, tu peux très bien ne pas utiliser la chaine de connexion du fichier web.config et créer une chaine spécifique dans chacun de tes sqlprovider.
Maintenant, tu as aussi la solution de créer une base avec une instance séparée de dnn par portail. Ce serait bien plus simple à maintenir et tu conserverais ainsi la compatibilité de tes modules. De plus, tu pourrais alors créer un pool d'application par portail. Ce qui peux être utile au cas ou un portail plante, les autres continuerons de tourner. Seulement avec une centaine de portails, les mises à jours te prendrons plus de temps. Mais bon, il faut voir, tu n'es pas obligé non plus de créer une instance par portail. Peut-être suffirat-il de créer une dizaine d'instances avec une dizaine de sites chacune, compte tenu que tu sais déjà que tu auras une centaine de sites, j'en déduis qu'il s'agit d'un projet pour une grosse entreprise. Dans ce cas, peut-être est-il possible de faire des sub-division par entité ?
En théorie, il n'y a pas de limite au nombre de portails par instance. Car l'id de portail est un entier 32 bits, soit un peu plus de 2 milliards de portails par instance. En fait, c'est plutôt du côté de SQL Server qu'il faut imaginer les optimisations. Car tout le gros du travail est efffectué par lui. L'idéal serait d'avoir un serveur avec IIS et les instances de dnn et un second serveur pour SQL Server et toutes les bases des différentes instances. Sachant que SQL Server est plus rapide s'il dispose d'un maximum de mémoire vive, je dirais que le serveur web pourrait être un bi-proc avec 1Go de ram, et le second un bi-proc avec 2 ou 4 Go de ram.
Gilles