Discussion :

[saninx]

Bonjour, je suis ici ce matin à la recherche d'avis d'expert.
j'ai une application Multi-clients en web et je ne sais vraiment pas comment la déployer.
- mon objectif était que chaque client ait son environnement et sa base bien à lui, ou une application qui peut se connecter à plusieurs base (une base par client).
- cependant pour éviter d'avoir à la fin de nombreuses applications et base je veux maintenant créer une base qui contiendra les données de tous les clients et chaque client n'aura accès qu'à ses données. cependant vu qu'il y aura des milliers de données enregistrées par jour par client imaginez dans 2 ou 3 ans quand le nombre de clients augmentera, vu qu'il est illimité ce que cette base risque d'être.

quelle serait selon vous la meilleur manière de déployer ce genre de solutions.

Merci de bien vouloir me guider.

[escartefigue]

Bonjour,

Avec d'autres SGBD que MySQL, une solution simple est d'utiliser les schéma : chaque client a un schéma dédié et les droits qui vont avec.
Malheureusement, MySQL ne fait aucune différence entre database et schema.

[saninx]

La solution que j'ai trouver est de créer une base pour chaque client.

[Artemus24]

Salut à tous.

@ saninx : je pense que ce n'est pas une bonne idée de créer une base de données pour chaque client que vous aurez dans le futur.
Et si vous aviez deux cents clients ?

je veux maintenant créer une base qui contiendra les données de tous les clients et chaque client n'aura accès qu'à ses données.

C'est la bonne façon de faire. Le problème est la volumétrie que vous aurez.

cependant vu qu'il y aura des milliers de données enregistrées par jour par client imaginez dans 2 ou 3 ans quand le nombre de clients augmentera, vu qu'il est illimité ce que cette base risque d'être.

Il ne faut pas être défaitiste.

Vous devez chiffrer la volumétrie quotidienne.
Si c'est deux mille lignes par jour, en un an, cela fait 730 000. Disons 800 000 lignes.
Et si vous avez 200 clients, au bout de 3 ans, cela donne une volumétrie de 480 millions de lignes. On arrondis à 500 millions.
C'est pas si gigantesque que cela.

Que faire des anciennes lignes ? On peut les archiver d'où prévoir une gestion des tables par partitions.
Par exemple, une table partition par mois.

Les accès aux lignes du client doivent se faire par des view.
De ce fait, vous devez gérer des comptes, un par client.
Il y a des sujets qui ont été traités dans developper sur la gstion des view.

Il est vrai que pour des très grosses volumétries, mysql n'est pas fait pour cela.
Il vaut mieux se diriger vers quelque chose de plus professionnel, comme Microsoft SQL Server.

quelle serait selon vous la meilleur manière de déployer ce genre de solutions.

Ce genre de question ne se pose pas en fin de projet.
C'est du domaine de la faisabilité, là où l'on doit prévoir le type de SGBDR que l'on doit acheter.
Ainsi que le chiffrement de votre projet et sa durabilité.
Par exemple, un maximum de 200 clients pour une durée de vie de 10 ans.

Prévoir aussi un serveur en conséquence.
Nombre de cœurs, taille maximale de la ram, nombre de disques dur, procédure de sauvegarde, ...
Et je n'aborde même pas les problèmes de sécurités.

On ne s'improvise pas DBA. C'est un métier !

@+