Discussion :

[yvancoyaud]

Bonjour à tous

J'ai besoins de ranger, dans une base MySQL les données d'un grand nombre de clients (>1000). "L'espace de travail" de chaque client comporte une cinquantaine de tables. Pour caractériser les tables d'un client, le nom des tables est préfixé par un numéro de client.
- faut-il tout mettre dans la même base avec plus de 50 000 tables !!!
- faut-il limiter le nombre de client par base de données et multiplier le nombre de base de données. (100 clients par base sur 10 bases)

Dans quel cas aura-t-on les meilleures performances ?
Merci de vos lumières.
YC

[CinePhil]

Il vaut mieux faire une seule BDD et ne pas faire des tables par client !
Il suffit d'une clé étrangère dans les tables pour différentier les données entre les clients.

[yvancoyaud]

OK, là c'est pas du tout ce que j'avais prévu !!!
Bien sûr la gestion devient tout d'un coup plus simple... mais mes tables risque prendre des tailles colossales !!
Je n'ai pas fait une étude très précise des volumes par client, mais je pense que chaque clients pèsera en moyenne 300Mo et donc 1000 clients 300Go
Ça m'effraye un peu !

Cette grande tailles des tables ne risque telle pas plomber les temps de réponses ?

Merci pour ta réponse.
YC

[CinePhil]

1000 clients, ce n'est vraiment pas beaucoup. Quelles données font qu'il y a 300 Mo par client ? Aurais-tu stocké des fichiers dans la BDD ?

[yvancoyaud]

En fait, tout ça existe déjà chez les clients, mais sous forme d'applications installées sur PC exploitant une base de données informix sur un serveur local UNIX. Entre 5 et 10 postes par clients. Les bases de donnée informix font environ 300Mo. L'une d'elle fait même 500Mo.
Voila ce qui est a l'origine de mes déductions de taille.
Aujourd'hui nous avons de bonnes performances, tout étant un peu surdimensionné.
Les données sont des très gros textes des scans et un ensemble de données propres a chaque client (de nos client). Bien sur on devrait pouvoir faire mieux et améliorer la taille des données mais ce n'est pas a l'ordre du jour.

Je ne voudrais pas qu'en externalisant les données on perde trop de performances.

[CinePhil]

Je ne sais pas comment Informix gère les fichiers en BDD. Peut-être utilise t-il le même principe que SQL Server qui ne stocke pas réellement les fichiers en BDD mais dans un espace de stockage qu'il contrôle entièrement, ce qui fait que le volume de données est moins important.

En MySQL, il est recommandé de ne stocker en BDD que le nom du fichier et d'enregistrer les fichiers réels dans un espace de stockage séparé de la BDD. C'est le programme applicatif qui s'occupe alors du téléchargement des fichiers vers l'espace de stockage et qui va les lire à partir des informations fournies par la BDD.

Voir l'article de SQLPro à ce sujet.

Mais puisque tout est sur Informix chez les clients, pourquoi vouloir tout mettre sur MySQL chez toi ? Les types de colonnes sont-ils identiques ? Les fonctions utilisées dans les BDD Informix sont-elles toutes compatibles avec ce que sait faire MySQL ?

Bref, il faut étudier ça plus en détail et commencer par se demander pourquoi vous voulez rapatrier toutes les données des clients chez vous. En avez vous même le droit étant donné que les données des clients leur appartiennent ?

[yvancoyaud]

Non, on ne rapatrie rien "chez-nous".
En fait l'application est en cours de réécriture pour être une application RIA (avec Flex) et sera accessible à partir d'une connexion internet. Les données seront alors sur un serveur virtualisé accédé par l'application.
Donc serveur avec Linux, PHP de donc MySQL. Ceci explique cela.
Quand aux données elles appartiennent effectivement au client, on ne fait que s'occuper de leur hébergement et de leur gestion. Ils peuvent les récupérer a tout moment.
Cette nouvelle organisation apporte beaucoup d'avantage (Plus de serveur locaux a des prix exorbitant, disponibilité des applications n'importe où etc.)
Mais il ne faut pas que les performances s'écroulent...
D'où mes interrogations sur la façon d'organiser mes ou ma base de données.

[CinePhil]

Donc serveur avec Linux, PHP de donc MySQL.

Pourquoi "donc MySQL" ?

Vu le volume de données et le nombre potentiel de clients susceptibles de se connecter simultanément, je préconiserait plutôt un vrai SGBDR genre MS SQL Server (exclusivement sous Windows), Oracle, ou en libre Postgresql. Il paraît que Firebird est pas mal aussi d'après les commentaires d'un récent sondage sur DVP.

Mais MySQL a tellement de défauts que pour une vraie utilisation professionnelle il vaut mieux l'éviter.

Et puisque vous êtes en phase de réécriture, pensez à réviser votre modèle de données en faisant une seule BDD qui ne stocke pas les fichiers. Dans la norme SQL, ce procédé de contrôle total par le SGBD des fichiers associés aux données s'appelle le DATALINK (FILESTREAM chez SQL Server).

[yvancoyaud]

"donc MySQL" c'est juste que lorsque l'on parle hébergement, on entend tout de suite Linux, Apache, PHP et MySQL. Et tout fait tendre vers ça. Flex par exemple avec Zend est orienté vers MySQL et offre des bibliothèques Php accédant une base MySQL.
FireBird je l'ai utilisé quand c’était Interbase de Borland et déjà à cette époque c'était un SGBD robuste, fiable et avec de nombreuses fonctionnalités. Et puis pour des raisons de business il est tombé en désuétude pour renaitre sous FireBird. Aujourd'hui, est-il vraiment utilisé ?
Nous sommes une toutes petite société et sous-traitons tout ce que nous n'avons pas le temps ou pas la compétence de faire. Il est plus facile de trouver des compétence MySQL que Firebird.

Bon je pensais que mon problème de base de données était résolu, mais je crois qu'il faut que je réfléchisse encore un peu

En attendant chez moi il est minuit, je vais me coucher.
Merci de t’être intéresser à mon problème.

YC

[CinePhil]

Zend Framework utilise PDO qui peut adresser n'importe quelle BDD. C'est justement l'avantage de PDO de pouvoir garder la même application avec des SGBD différents.

[ericd69]

salut,

cinephil a raison ça peut ne pas être simple de faire la transition entre 2 sgbd vu qu'aucun ne respectent les même règles de stockage ou même à 100% la norme sql niveau langage...

par contre, un certain nombre de sgbd étant en fin course ça peut être une tache pénible mais nécessaire...

après tu as généralement des solutions techniques à tout...

le partitionnement manuel comme tu le pensais peut être fait de manière consistante vu que mysql supporte le partitionnement d'une table de très grande taille par exemple pour accélérer certains traitements et garder une cohérence sur les index, dispatching de partitions sur différents DD si besoin, etc...

après comme te le suggère cinephil le changement de sgbd peut aussi être le bon moment pour repenser le modèle de données...