Salut à tous
 
Il faut que je crée un site qui génère des copies de lui-même, pour être ensuite indépendantes. Ca a l'air compliqué comme ça, mais en fait le principe est simple
 
Donc j'aimerai avoir votre avis :  
Vaut-il mieux que chaque site dispose de sa propre base de données sur le MySQL, que chaque site ait son jeu de tables (avec un préfixe, genre site1_table1, site2_table1...), ou encore que chaque enregistrement de chaque site soit identifié dans la base par un champ spécifique (méthode complètement suicidaire selon moi).
 
Oui, je sais, à problème complexe question complexe
 
En tout cas merci d'avances pour vos conseils

Je vote pour 1 base par site, mais avec 1 seul serveur.
Plusieurs avantages :
- vraie séparation des données, avec la possibilité de créer un user par site qui ne peut accéder qu'à la base correspondante
- le code n'a pas à se préoccuper de cette problèmatique (inutile de prévoir un filtre dans les requêtes pour ne pas traiter les enregistrements des autres sites). Il faut juste définir le nom de la base à la connexion (facile à paramétrer)
- même serveur, donc pas compliqué de dupliquer un site (copie des données d'une table à une autre)
 
Ca n'interdit pas d'avoir aussi une base pour les données vraiment communes

Merci pour la réponse
 
C'est effectivement ce qui me semble le plus logique et facile à maintenir, après il faudrait que je génère des stats à partir de données de l'ensemble des sites. Ces stats ne seraient pas énormément consultées, mais lors de la requête ça peut faire mal au mySQL de changer 100 fois de bases de données...

Moi je suis moins ouvert à la méthode "une base par site".
 
J'ai déjà vu un système de ce genre chez un client.
 
Si derrière, ton "site" a le même code source pour chaque "sites", alors on est bien d'accord qu'une modif sur une base devra être répliquée sur toutes les bases.
 
Je te conseille de partager ton code source du site si c'est possible afin de minimiser les devs lors d'upgrades et pouvoir faire bénéficier tous les sites en même temps de la même correction de bug/évolution.
 
Dans ce cas, si tu as X bases, alors la moindre modif dans le code source va faire planter tous les sites sauf celui sur lequel tu travailles. C'est relativement pas terrible du tout.
 
Du coup, moi je préconise plutôt un champ "site_id" dans toutes les tables. Cela a aussi l'intérêt, moyennant assez peu de travail, de rendre des données communes entre plusieurs sites.
 
Genre t'as une liste de pays ou autres infos "fixes", tu peux parfaitement les mettre avec un site_id = 0 et une table de paramétrage t'indique que la table des pays doit être utilisée avec site_id = 0 et non site_id = {site}
 
En fait, ça dépend surtout de ce que ton site fait.
 
Je travaille sur Générix, qui existe depuis quelques années en mode web.
De base, on a un site btoe et un site btob (ainsi qu'une série d'autres mais j'ai pas trop creusé).
Les deux sites tapent dans la même base et le même serveur d'appli.
Et à la fois les sites et la base sont prévus "multi-société". Ainsi une centrale, via le site, voit ses propres données ainsi que celle de ses franchisés, tandis que chaque franchisé ne voit que ses propres données (par exemple, tout est paramétrable).
C'est le principal intérêt de tout laisser dans la même base : quand tu as besoin de gérer une hiérachie ou de partager des données d'un site à l'autre, ça se fait tout seul.

Voilà c'est à ça que j'avais pensé. Je pense que c'est la solution la plus rapide mais la moins "propre" : chaque site aurait son site_id, chaque enregistrement dans une table comprendrait ce site_id via un champ spécifique, comme tu disais.
Mais ça implique de devoir faire une conditions supplémentaire pour toutes les requêtes et je doute que ce soit "pratique"... Genre pour toutes les requêtes

 
Ca serait la solution la plus pratique, mais je suis quand même hésitant...

pour chaque site, une base spécifique, un fichier de config spécifiques et des fichiers php spécifiques  
 
la gestion des mises a jour des fichiers .php se fait tres simplement avec un gestionnaire de source( git, mercurial , svn ,... )  
 
Avantage :  

• tu peux faire une modif spécifique sur un site en cas de besoin  
• un problème sur un site ne touche pas les autres  
• si un des sites doit etre migré sur un serveur spécifiques , ca ne pose pas de pb