Discussion :

[YokhoJota]

Bonjour,

Je n'arrive pas à me décider sur la solution la plus simple/pérenne/performante concernant la base de données d'un logiciel en PHP/MySQL.

Des utilisateurs s'inscrivent et peuvent créer des projets.
Il y a environ 15 tables dont l'une d'elle est un peu particulière, car c'est l'utilisateur qui va choisir les colonnes pour un projet donné.

La question ne se pose pas vraiment pour 10 projets, mais pour 100, 1000, 10000 projets mieux vaut faire les choses proprement dès le départ.

1. Pour chaque projet on créé une base de données avec les 15 tables et l'utilisateur modifie à loisir sa table spéciale ? (100, 1000, 10000 bases de données...)
2. On met tous les projets dans une seule base de données et on créé une table spéciale pour chaque projet ? (100, 1000, 10000 tables...)
3. On ne met qu'une table spéciale mais avec beaucoup de champs (par exemple 50) ? (du coup plusieurs millions de lignes avec de nombreuses colonnes)
4. On met cette table spéciale en EAV (entity-attribut-value) ?
5. Un mixe de plusieurs solutions ?
6. Autre ?
7. Ne se prononce pas.
8. Obiwan Kenobi.

Le tout sur un serveur dédié OVH.

Merci pour vos lumières,

Yokho

[vmolines]

Une seule base et une modélisation par méta données pour les colonnes "spéciales".

Attention il y a quand même des contraintes avec ce type de modélisation et ce n'est pas forcément adapté si vous devez mettre beaucoup d'intelligence dans ces données.

[CinePhil]

Pour chaque projet on créé une base de données avec les 15 tables

Ça commence très mal !

La question ne se pose pas vraiment pour 10 projets, mais pour 100, 1000, 10000 projets

Donc 150 000 tables ?

Je te conseille vivement de proposer ton modèle de données dans le forum Schéma.

[YokhoJota]

J'ai peut être mal exposer le problème.
Je recommence :

Notre petit logiciel de gestion de contacts est composé de 15 tables.
Un utilisateur s'inscrit, créé son projet, entre ses contacts, gère des envois de lettres, etc.
On peut avoir 1000 utilisateurs, 1000 projets, etc.
Une base de données, 15 tables. Classique.

Ensuite je voudrais pouvoir donner la possibilité aux utilisateurs de personnaliser les champs de saisie pour leurs contacts dans un projet donné. Dans tel projet on a juste "nom, prénom, courriel", dans tel autre 50 champs avec des adresses, sites, téléphone, etc.
Comment faire au mieux? Si l'on vise 100 projets? 1000 projets? 10000 projets?

Je propose toutes les solutions auxquelles j'ai pensé. Si certaines sont ridicules ou dangereuses quand on atteint les 100, 1000 ou 10000 projets, c'est toujours bon à savoir.

Les meta données proposées par vmolines sont en fait - si j'ai bien compris - de l'EAV appliqué à une portion de table. Solution qui me paraît la meilleur à l'heure actuelle.

Merci pour vos réponses.

Yokho

[tse_jc]

Bonjour,

La meilleure solution reste à mon sens de travailler sur un seul schéma et une seule BD. Sachez qu'en terme de cloisonnement ce n'est pas en scindant physiquement les tables que vous garantirez l'isolation des données par utilisateur et/ou par projet. Cette isolation peut parfaitement être gérée en les stockant dans une même table avec une intégrité garantie.

Le problème, à mon sens tiens à votre modèle de gestion. Vous souhaitez en effet maintenir la gestion future de votre BD avec votre applicatif existant ce qui pose un double problème :

1) on ne gère pas une BD à partir d'un applicatif, c'est la BD qui doit gérer l'applicatif
2) Votre applicatif actuel ne réponds pas à votre cahier des charges et donc il n'est pas envisageable de le maintenir pour votre projet en l'état actuel des choses.

Si la volumétrie reste importante, vous pourrez toujours recourir au sharding au sein de votre modèle, mais pour ce faire, SQL Server sera pour le moins le plus adapté, car postGreSQL est un peu léger question gestion shards.

++

[CinePhil]

1) on ne gère pas une BD à partir d'un applicatif, c'est la BD qui doit gérer l'applicatif

Je ne dirais pas ça de cette manière mais plutôt ceci :
Ce n'est pas l'applicatif qui dicte la structure des données. On modélise d'abord les données puis l'applicatif doit s'adapter à la structure de données qu'on a construite.

En principe, on ne touche plus à un modèle de données une fois établi, sauf évolution significative des besoins ou des règles de gestion des données.

[YokhoJota]

Merci!