plusieurs BDD ou 1 BDD avec des prefixes ???

[raljx]

Ch'tite question aux spécialistes !

Dans le cadre du developpement d'un outil disponible pour l'utilisateur et utilisant 1 bdd mysql d'environ 25 tables, vaut mieux :

1 BDD Mysql unique avec un prefixe de table 'XXXXXX_' pour chaque utilisateur
ou
1 BDD Mysql par utilisateur

???

Madri me balance pas tes liens suis déjà présenté :mrgreen: pi j'dis plus bonjour ^^

 

[UsagiYojimbo]

Pour donner un exemple, wordpress MU crée des tables pour chacun des blogs en les préfixant.

 

[raljx]

tiens vi! j'avais pas pensé a WMU ...
je suis curieux de la charge des serveurs !!

 

[dmathieu]

WPMU se base sur Wordpress, qui ne permet pas de créer des plateformes multiblogs par défaut.

Si tu es en train de développer l'application, tu as dont la possibilité de faire encore mieux niveau performance : une seule base de données.
Tous tes utilisateurs peuvent alors récupérer leurs données depuis cette base, c'est à toi de construire les requêtes correctement pour qu'ils ne puissent pas récupérer celles des autres.

Avoir plusieurs bases impose de se connecter et de se déconnecter de celle-ci en quasi permanence. Et ça c'est pas bon.
Avoir une table par utilisateur c'est pas maintenable.
Quand tu as besoin de modifier ton schema, tu dois le faire sur les 5 000 tables qui existent.

 

[jv2759]

Je dirait que pour un petit volume de donnai une seul base à des avantage car pas besoin de jongler. Par contre si cela doit monter en volume, avoir une seul base énorme n'est pas forcement une bonne chose, car plus lourd à manipuler, pour le système mais aussi pour toi... De plus un client=1 base tu peux envisager si le besoin ce fait sentir de migrer certaine base sur d'autres serveur si jamais la charge devenais trop lourd.

Je dirait de bien évaluer la charge que représenteras les base, si c'est critique, alors le multi base offrira une plus grand souplesse (qui imposera plus de travail pour certaine tache, ). Si cela ne l'ais pas du mono base seras plus simple à gérer.

Tous tes utilisateurs peuvent alors récupérer leurs données depuis cette base, c'est à toi de construire les requêtes correctement pour qu'ils ne puissent pas récupérer celles des autres.

A condition que le volume de donner soit raisonnable et une bonne maitrise de mysql . Sinon cela peux exploser en terme de traitement.
De plus une merde sur un enregistrement et c'est 100% des clients qui sont bloquer.

Avoir plusieurs bases impose de se connecter et de se déconnecter de celle-ci en quasi permanence.

Pas forcement, si chaque clients et indépendant il ne doit ce connecter qu'à sa base à lui. Et si c'est du web, de tout façon il le fait.

 

[raljx]

Je pense que je vais partir sur 1 base par client (plus gérable pour tout ce qui est sauvegarde et transfert), moins dangereux si une table crashe (service toujours online pour les clients sans problème) et voir un peut la charge induite ...

 

[Aaarrrgggh]

Tout dépend de ce que tu comptes faire de l'outil :

si celui-ci risque d'être évolutif, il vaut peut-être mieux utiliser une seule base de données, chaque table pourrait intégrer une clé étrangère id_membre ou équivalent, qui permet de rapatrier tous les enregistrements du client concerné. Ainsi, en cas de mise à jour du service, tu n'aurais qu'une base à modifier. En ce qui concerne les crashs, bien sûr, à faire gaffe, mais ne jamais oublier de faire des sauvegardes régulières (quotidiennes ou même deux fois par jour). Pour tout ce qui est export et sauvegarde, y a juste à créer un petit script perso.

Dans le cas contraire, tu peux effectivement utiliser plusieurs bases. Mais niveau maintenance, gestion et mise àjour, je doute que cela soit vraiment l'idéal.

 

[raljx]

Je gère les backups avec des cron (l'avantage est que tu peux leur donner des valeurs dynamiques)... donc tout est automatisé. Je pense que dans l'avenir, le gros du morceau va être l'espace disque et l'optimisation mysql.

 

[Julia41]

Ca revient au même, mysql se "fiche" de savoir "à qui" est la table, pour lui c'est une table identifié par :
base_de_donnée.table.
C'est pour ça que la seule chose sur laquelle tu peux jouer dans la config est le "table_cache".
En séparant par user, tu gagnes en sécurité (si tu te fais hacker une base de données, il n'a accès qu'à cette base).
En séparant par user, tu perds en facilité (toujours même login/pass à mettre dans les config.php).

Tu gagneras toutefois un peu en vitesse (mais c'est minime) en séparant. MySQL ne s'embêtera pas à mettre en cache le nom des tables pour une base de données qui ne sert jamais (un site que tu n'utilises plus).

Pour l'optimisation, tu as les tuning-primer.sh et mysqltuner.pl qui te permettront de faire le gros du travail. Les INDEX SQL t'aideront pas mal aussi.