Discussion :

[manaboko]

bonjour à tous, moi, je conçois un grand site portail, d'un pays, et on voit tout dedans, e-commerce, tchat, petites annonces, forum,... avec plusieurs rubriques à la clé.
je voulais séparer les rubriques comme de mini-site, donc chaque rubrique possède sa propre interface d'administration et son fichier de configuration. Mon petit problème est qu'il y a une partie espace membre: une fois connecté sur une rubrique, le membre est connecté sur toutes les autres rubriques, exactement comme Yahoo!

questions:
- faut il utiliser une seule base de données pour tout le site? MySQL est-il assez grand pour supporter un grand site? puisque si MySQL est assez grand pour supporter un site comme Yahoo!, alors mon problème est résolu
- si on utilisera plusieurs bases, doit-on utiliser une base commune pour les utilisateurs, et une gestion des utilisateurs à part? à noter qu'il y a des fonctionnalités dans les rubriques qui sont liés à ces utilisateurs

merci d'avance pour vos réponses

[SirDarken]

Concrétement si tu utilise une ou plusieurs bases d'un même serveur, je voie pas pourquoi ne pas tout faire dans 1 seule base.

Aprés je pense que c'est au niveau conception que tu peux je dirai découper ton application, sépare tout le coté "gestion client" et "gestion site", enfin il faudrai détailler plus les fonctionnalitées de ce que tu veux faire.

Personnellement je ferai comme suit:

-Base client : gère l'identification, les services clients, leur proposition (leurs sites ou autres)
-Base site : gère ton site, les rubriques, le contenu ect.

-Panneau d'administration transferant vers la base site les porpositions de la base client aprés vérification de ta part (ou de l'admin).
Déja ca te permet de couper leprojet en deux, et si ta un souci coté client ca te casse pas le reste.

Aprés voila si j'ai mal compris ta réquête hésite pas à en dire plus.

[sabotage]

Comme le dit SirDarken, si toutes tes bases sont sur le meme serveur, en terme de performance ca ne va pas changer grand chose d'en faire un grosse et plusieurs petites.
Ca peut changer la donne en termes de taille de base, mais avant d'atteindre la taille maximale tu as du temps.

Pour info, Yahoo annonce avoir 1 petabyte de données et 1000 serveurs et ils utilisent Postgres.
Quand tu en seras la, previens nous.

[manaboko]

je veux vraiment dire une très grande site, peut-être pas comme Yahoo! pour la taille, mais pour les fonctionnalités oui, il y a assez de similitudes. Donc, je ré-explique mon soucis:
Sachant que :
1/le site possède des rubriques
2/chaque rubrique est assez grande et possède des sous-rubriques
3/une sous rubrique est considéré comme un site, par exemple un site sur l'automobile, genre http://www.turbo.br/
4/chaque rubrique possède sa propre interface d'administration
5/il faut gérer les connexions des utilisateurs sur tout le site, façon yahoo!, c'est-à-dire, l'utilisateur se connecte une seule fois sur un rubrique et il est alors connecté sur un site tout entier, encore genre Yahoo!, tu te connectes une seule fois sur Yahoo!Sports et tu peux est connectée sur tout Yahoo, que ce soit finances, jeux, mail, .fr, ou .com

Ma question est: est-ce qu'il faut utiliser une plusieurs bases de données pour ce genre de site, en particulier pour les connexions utilisateurs communes? puisque déjà, il y a possibilité de mettre les rubriques dans de sous-domaines

[sabotage]

Que les tables soient dans la meme base ou dans des bases differentes c'est juste question de la facon dont tu aimes organiser tes données.
Au niveau des fonctionnalités ca ne change rien.

[manaboko]

j'ai l'impression d'être mal compris, le problème est la gestion des utilisateurs connectés, et je ne vois pas pour l'instant la relation entre l'organisation des données.
-si j'utiliserai plusieurs bases de données, il faut donc soit;
a/que chaque rubrique se connecte à deux bases de données: une connection pour les fonctionnalités propres à la rubrique et qui n'a pas de relations avec l'utilisateur connecté
b/une connection pour les fonctionnalités liées à l'utilisateur connecté, qui utilise en même temps, les tables propres à la rubrique

si il n'y a pas de gestions d'utilisateurs, il y a pas de problèmes si j'utilise une ou plusieurs bases, je le sais

[kaymak]

ouaip enfin yahoo ils ont choisi openid ! ...
http://openid.yahoo.com/
http://www.google.fr/search?hl=fr&q=openid&meta=

a plus

[sabotage]

que chaque rubrique se connecte à deux bases de données

tu peux utiliser toutes les bases du serveur avec une seule connexion.

[manaboko]

la question n'est pas si je peux utiliser une Connection pour toutes les bases du serveur, bien sûr que je le peux, mais , quelle est la solution pour gérer les sessions d'utilisateurs si il y a un risque que le site soit repartis en plusieurs sites avec plusieurs sous-domaines en tenant compte qu'il n'y aura pas de connexions utilisateurs à chaque fois.

kaymak a compris la question, mais est-ce qu'OpenId résout les problèmes que l'utilisateur connecté a droit d'écrire dans le forum d'une rubrique ou que seulement il est connecté et c'est tout?

merci d'avance

[manaboko]

mais OpenId est il paramétrable? je ne le connais pas encore assez, mais j'ai l'impression que question confidentialité, c'est limite

[manaboko]

et d'après ce que je lit actuellement, openid est en fait une liaison de compte, si tu as un compte yahoo, tu le lie à openid et ensuite si tu te connectes à yahoo, alors tu es aussi connecté sur tous les sites utilisant openid, c'est à peu près ça?

[sabotage]

la question n'est pas si je peux utiliser une Connection pour toutes les bases du serveur

Ce n'est pas de ma faute si tu parles de base de donnée, de performance mysql et de taille de base depuis le début comme étant ton problème.

Si la question est finalement la propagation de session a travers plusieurs sites, tu peux tres bien faire une gestion des sessions sur la base de donnée commune.

[kaymak]

openid c'est comme une grosse base de données couplée à un webservice. Je me suis pas interessé dans le détail à ce projet, mais l'idée c'est de dire qu'un compte utilisateur sur un site A ou B, c'est à peu ou prou la même chose. Donc on peut centraliser tout cela.

C'est a ce moment qu'intervient openid puisqu'il centralise tout cela.

Après pour l'implémentation je n'en ai strictement aucune idée....

et d'après ce que je lit actuellement, openid est en fait une liaison de compte, si tu as un compte yahoo, tu le lie à openid et ensuite si tu te connectes à yahoo, alors tu es aussi connecté sur tous les sites utilisant openid, c'est à peu près ça?

Oui c'est le but du projet.

mais est-ce qu'OpenId résout les problèmes que l'utilisateur connecté a droit d'écrire dans le forum d'une rubrique ou que seulement il est connecté et c'est tout?

Non certainement pas, cela relève de ton domaine métier.

Maintenant si j'ai cité l'exemple c'est parce que derrière j'imagine qu'ils ont mis en place un webservice commun à tous les sites de yahoo qui permet de gérer l'identification d'un utilisateur.
Bref ils ont du découpler à fond l'utilisateur de l'ensemble de leurs applications.
Ce que tu souhaites faire.

Après a savoir si tu dois utiliser une ou plusieurs bases de données pour une question de performance.Amha, cette question importe peu. Car mysql possède des solutions de clustering et permet donc de monter en capacité de manière très importante.

La question qui t'importe c'est comment mes sites vont interagir, être déployé. Si mes sites doivent être indépendant physiquement, cela aura des impacts sur ce fameux service des utilisateurs.
Par contre si tous mes sites peuvent être contenus sur la même machine, ou cluster, ton service sera peut être disposé autrement, ne serait ce que pour profiter d'un gain de performances, d'une simplification de l'application.
Bref, il me semble que tu dois dessiner ton service en fonction de ton besoin. Soit tu utiliseras une seule base de données pour tous tes sites, soit plusieurs, pour les raisons suscités en exemple. Ou bien peut être décideras tu d'utiliser des webservices pour complètement découpler les différents sites tout en assurant un suivit intègre du compte utilisateur.

Y'à le choix, la question est de savoir ce qui est vraiment nécessaire.

Du moins c'est ce que j'en pense.

bye

[manaboko]

si on n'utilise pas openid, si les bases seront separées pour chaque sous-rubrique, comment gérer au max les sessions des utilisateurs, et comment gérer les fonctionnalités reliés aux utilisateurs authentifiés: en utilisant la variable $_SESSION ou en intégrant les sessions dans la base de donnée?

[kaymak]

Si tu utilises un service centralisé pour gérer tes utilisateurs, il me semble qu'une base de données ne serait pas de mal pour gérer les sessions et leur durée de vie..

[manaboko]

donc entre une table utilisateur pour chaque rubrique( donc pour deux rubriques, deux tables utilisateurs), et une table utilisateur pour le site en entier, quelle solution prendre? c'est-à-dire séparer le site en plusieurs sites suivant les rubriques existants (maintenance plus facile), ou ne pas le séparer

j'essaye en même temps, tout en attendant les réponses de votre part. Merci.