Slt,
Une petite question aux spécialistes de MySQL.
Supposons un outil utilisé par plusieurs personnes.
Ces personnes peuvent alimenter plusieurs tables d'une bdd avec, possiblement, des millions de lignes.
Ces personnes n’ont aucune interaction entre elles.
Comment structurer au départ pour ne pas créer de charges serveurs trop sévère et impacter les autres personnes, lors, par exemple, d'une utilisation massive par l'une d'elles.
Une base avec des tables communes ?
Une base avec chacun ces tables ?
Une base par client ?
Merci pour vos retours.
la communauté d'entraide francophone dédiée au PHP
Structure bdd multi utilisation
salut,
il y a plusieurs réponses possible.
La réponse simple mais qui complexifie la maintenance de l'architecture c'est d'avoir une base par client / utilisateur. La tu es certain que le mec qui sollicite trop la base n'impact que lui.
Multi plier les tables par clients / utilisateurs c'est une connerie (avec des tables, users_toto, users_tata, users_droit_tata,users_droit_toto ...) tu va au devant des emmerde.
Avoir les mêmes tables pour tout le monde c'est la solutions simple généralement utilisé et qui satisfait la plus part des cas.
Par contre il y a la possibilité d'un client / utilisateur qui sollicite plus la base que les autres.
Un DBA peux régler la chose, par exemple en utilisant les quotas (notamment de connexion simultanée), c'est ce que fait un hébergeur qui n'as pas une instance par client hébergé, mais des pleins de client sur une même instance.
un autre problème c'est qu'un grand nombre de données peux ralentir les opérations, la il faut te pencher sur l'optimisation de ta base de données (bien mettre un index sur la clef étrangère qui identifie le client / utilisateur, ainsi que sur les colonnes utiles dans les recherches).
L'optimisation d'une base de données c'est pas mal de taf et parfois de dé-normalisation
Les sgbd peuvent encaisser de grosse sollicitation et des gros volumes de données, as toi de voir quel sera le volume réel que tu estimes pour éviter une migration d'architecture coûteuse.
j'allais oublier, dans la vrai les serveurs de données ne sont pas seul, ils sont redondés et / ou en cluster ce qui signifie, que la charge est répartie sur plusieurs serveur et donc le problème est moindre.
C'est une solution souvent obligatoire que de passer par l'architecture afin d'absorber une partie de la charge.
@+
il y a plusieurs réponses possible.
La réponse simple mais qui complexifie la maintenance de l'architecture c'est d'avoir une base par client / utilisateur. La tu es certain que le mec qui sollicite trop la base n'impact que lui.
Multi plier les tables par clients / utilisateurs c'est une connerie (avec des tables, users_toto, users_tata, users_droit_tata,users_droit_toto ...) tu va au devant des emmerde.
Avoir les mêmes tables pour tout le monde c'est la solutions simple généralement utilisé et qui satisfait la plus part des cas.
Par contre il y a la possibilité d'un client / utilisateur qui sollicite plus la base que les autres.
Un DBA peux régler la chose, par exemple en utilisant les quotas (notamment de connexion simultanée), c'est ce que fait un hébergeur qui n'as pas une instance par client hébergé, mais des pleins de client sur une même instance.
un autre problème c'est qu'un grand nombre de données peux ralentir les opérations, la il faut te pencher sur l'optimisation de ta base de données (bien mettre un index sur la clef étrangère qui identifie le client / utilisateur, ainsi que sur les colonnes utiles dans les recherches).
L'optimisation d'une base de données c'est pas mal de taf et parfois de dé-normalisation
Les sgbd peuvent encaisser de grosse sollicitation et des gros volumes de données, as toi de voir quel sera le volume réel que tu estimes pour éviter une migration d'architecture coûteuse.
j'allais oublier, dans la vrai les serveurs de données ne sont pas seul, ils sont redondés et / ou en cluster ce qui signifie, que la charge est répartie sur plusieurs serveur et donc le problème est moindre.
C'est une solution souvent obligatoire que de passer par l'architecture afin d'absorber une partie de la charge.
@+
Il en faut peu pour être heureux ......