Discussion :

[jordanChapuis]

Bonjour à tous,

Après plusieurs recherche je ne trouve pas ma solution alors je fait appel à vous.
Je souhaite concevoir une application web où les données seront créé par mes utilisateurs. Par exemple, sur cette application nous pourront décrire une "Structure" avec plusieurs paramètres de base : adresse, ville, code postal mais aussi des paramètres custom créé par l'utilisateur comme "capacité d’accueil" ou "accès handicapé", etc. Je ne peux donc pas utiliser une seule table "Structure" avec des champs statiques. J'ai lu le tutoriel de SQLPro : http://sqlpro.developpez.com/cours/m...n/metadonnees/ . Cette solution est parfaite pour moi et fait exactement ce que je souhaite faire! Seulement dans un autre post j'ai lu que cette méthode était devenu un peu obsolète. Ma question est donc comment réalisé ce que je veux faire avec des techniques plus actuelle? Je suis un peu perdu et ne trouve pas les mots clés pour trouver ce que je cherche.

Merci par avance pour vos réponses.

[CinePhil]

Quand j'étais à l'INRA, je travaillais sur une base de données qui était dérivée du principe des métadonnées.
Les données qui alimentaient cette BDD provenait de sources externes sous forme de fichiers plats.
Il y avait alors une partie métadonnées qui décrivait la structure des tables importées des fichiers plats et le logiciel travaillait avec les données importées en se servant de la description dans les métadonnées.

Dans votre cas, l'utilisateur peut ainsi créer par exemple une structure (Nom, Prénom, Sexe, Ville, Date de naissance, Taux handicap...) et importer les données tel quel dans une table créée pour la circonstance.
La structure serait, elle, enregistrée dans une base de métadonnées comprenant la description des tables et des colonnes, éventuellement les valeurs possibles (sexe : M ou F) ou plages de valeurs possibles (date de naissance comprise entre 1900 et aujourd'hui)...

Mais s'il doit y avoir des traitements globaux sur les données fournies par plusieurs utilisateurs, cette solution pourrait être contre performante avec un volume de données important, par rapport à une BDD normalisée, même si on ajoute des informations après coup.

[aieeeuuuuu]

bonjour,

Une alternative plus "moderne" consiste à utiliser l'XML.

[jordanChapuis]

Merci beaucoup pour vos réponses!

Du coup CinePhil, si je comprends bien la solution des métadonnées pourrait fonctionner dans mon cas et ne serait pas encore "dépassée"? Afin de préciser ce que je souhaite faire, je voudrais en fait créer une sorte de CRM destiné à faire de la diffusion de spectacles où un utilisateur pourrait construire son propre annuaire de structure. Ces structures serait par exemple des théâtres, des cafés théâtres, des salles de spectacles, etc...
L'utilisateur pourrait donc créer une structure, il devra alors remplir un champ obligatoire qui est le nom de la structure. Ensuite je voudrais lui proposer de créer ses propres champs à sa guise, comme par exemple "nombre de place assise" (qui serait un entier), "propose des spectacles jeune public?" (qui serait un booléen) ou bien "catégorie de salle" (qui sera une chaîne de caractères). Étant donné que chaque diffuseur (et donc utilisateur) a des besoins différents pour décrire les différents lieux de spectacles c'est pourquoi j'ai choisit d'opter pour cette façon de faire. Au niveau du traitement des données je vais seulement avoir besoin de faire des recherches de structure, par exemple une fenêtre de recherche avancé avec sélection de filtre, par exemple : chercher toutes les structures de type théâtre qui propose des spectacles jeune public et qui ont un nombre de place assise comprise entre 100 et 200.
Est ce que vous pensez que niveau performance la méthode des métadonnées serait adapté ou bien deviendrait trop complexe avec beaucoup de données?

Sinon pour répondre à aieeeuuuuu, j'ai vu en effet qu'il était possible d'utiliser du XML, seulement je travaille sur Mysql et il me semble que ce n'est pas possible avec ce SGBD, à moins que je me trompe? J'ai besoin d'un SGBD gratuit malheureusement. A moins qu'il y est d'autres SGBD gratuit qui puisse faire ceci?

[CinePhil]

un utilisateur pourrait construire son propre annuaire de structure. Ces structures serait par exemple des théâtres, des cafés théâtres, des salles de spectacles, etc...

Si votre besoin est limité à ça, je pense que vous pouvez avoir des données communes, telles que le type de lieu, la ville, le nombre de places et les données non communes laissées libres aux utilisateurs qui se créent leur propre annuaire pourrait être fait via les métadonnées.

je voudrais en fait créer une sorte de CRM destiné à faire de la diffusion de spectacles où un utilisateur pourrait construire son propre annuaire de structure.

Est-ce que vous vendrez la solution CRM, les utilisateurs étant alors le personnel de votre client qui aura installé le CRM chez lui ?
Ou bien est-ce que vous vendrez une prestation de service de CRM hébergée par vous et à laquelle les utilisateurs/clients viendront se connecter ?

Il me semble que, dans le second cas, il vaut mieux, pour que l'annuaire soit riche et attractif pour vos clients, que les données soient partagées et que l'ajout d'un type d'information par un utilisateur puisse éventuellement bénéficier à tous s'il s'agit d'une information à caractère publique. Le nombre de places en est une, le fait que la salle de spectacle ait accueilli 5 spectacles pour enfants l'an dernier ne l'est pas. C'est plus le besoin spécifique du producteur de spectacles pour enfants. Encore que vous pourriez collecter ces informations et les revendre à vos clients, j'imagine...

Dans le premier cas, chaque client à qui vous aurez vendu la solution CRM aura sa propre base de données et donc il ne regardera que ses propres données qui seront différentes de celles de son concurrent. Mais là vous transformez un peu votre agence de marketing en distributeur de solution informatique et ce n'est pas le même métier.

[jordanChapuis]

Merci encore pour le temps que vous accordez.

Est-ce que vous vendrez la solution CRM, les utilisateurs étant alors le personnel de votre client qui aura installé le CRM chez lui ?
Ou bien est-ce que vous vendrez une prestation de service de CRM hébergée par vous et à laquelle les utilisateurs/clients viendront se connecter ?

En effet je vais opter pour la deuxième solution en hébergeant mon application web moi même et chaque utilisateur aura son annuaire personnel sur son compte utilisateur.

Je vais donc partir sur ce schéma de BDD :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
 
CREATE TABLE T_STRUCTURE (
    id INT NOT NULL AUTO_INCREMENT,
    nom VARCHAR(50) NOT NULL,
    PRIMARY KEY (id)
)
ENGINE=INNODB;
 
CREATE TABLE T_CARACTERISTIQUE (
    id INT NOT NULL AUTO_INCREMENT,
    type_donnee_id INT NOT NULL,
    libelle CHAR(32) NOT NULL,
    PRIMARY KEY (id),
    FOREIGN KEY (type_donnee_id) REFERENCES T_TYPE_DONNEE(id)
)
ENGINE=INNODB;
 
CREATE TABLE T_CARACTERISTIQUE_STRUCTURE (
    id INT NOT NULL AUTO_INCREMENT,
    structure_id INT NOT NULL,
    caracteristique_id INT NOT NULL,
    valeur CHAR(32),
    PRIMARY KEY (id),
    FOREIGN KEY (structure_id) REFERENCES T_STRUCTURE(id),
    FOREIGN KEY (caracteristique_id) REFERENCES T_CARACTERISTIQUE(id)
)
ENGINE=INNODB;
 
 
CREATE TABLE T_TYPE_DONNEE (
    id INT NOT NULL AUTO_INCREMENT,
    sql_type char(16) NOT NULL,
    longueur INT NOT NULL,
    PRIMARY KEY (id)
)
ENGINE=INNODB;
 
 
CREATE TABLE T_VALEUR (
    id INT NOT NULL AUTO_INCREMENT,
    caracteristique_id INT NOT NULL,
    libelle CHAR(32) NOT NULL,
    PRIMARY KEY (id),
    FOREIGN KEY (caracteristique_id) REFERENCES T_CARACTERISTIQUE(id)
)
ENGINE=INNODB;

Est ce que ce modèle vous parait correcte et efficace?

Je vais également ajouter une table T_CONTACT qui sera lié à la table T_STRUCTURE (une structure aura plusieurs contact), qui elle aussi utilisera les métadonnées pour que chaque CONTACT appartenant à une structure puisse avoir des caractéristiques customs et ainsi pouvoir faire une recherche par structure et par contact. Niveau performance faire ceci ne changera pas beaucoup de chose non?

[SQLpro]

Merci beaucoup pour vos réponses!

Du coup CinePhil, si je comprends bien la solution des métadonnées pourrait fonctionner dans mon cas et ne serait pas encore "dépassée"? Afin de préciser ce que je souhaite faire, je voudrais en fait créer une sorte de CRM destiné à faire de la diffusion de spectacles où un utilisateur pourrait construire son propre annuaire de structure. Ces structures serait par exemple des théâtres, des cafés théâtres, des salles de spectacles, etc...
L'utilisateur pourrait donc créer une structure, il devra alors remplir un champ obligatoire qui est le nom de la structure. Ensuite je voudrais lui proposer de créer ses propres champs à sa guise, comme par exemple "nombre de place assise" (qui serait un entier), "propose des spectacles jeune public?" (qui serait un booléen) ou bien "catégorie de salle" (qui sera une chaîne de caractères). Étant donné que chaque diffuseur (et donc utilisateur) a des besoins différents pour décrire les différents lieux de spectacles c'est pourquoi j'ai choisit d'opter pour cette façon de faire. Au niveau du traitement des données je vais seulement avoir besoin de faire des recherches de structure, par exemple une fenêtre de recherche avancé avec sélection de filtre, par exemple : chercher toutes les structures de type théâtre qui propose des spectacles jeune public et qui ont un nombre de place assise comprise entre 100 et 200.
Est ce que vous pensez que niveau performance la méthode des métadonnées serait adapté ou bien deviendrait trop complexe avec beaucoup de données?

Sinon pour répondre à aieeeuuuuu, j'ai vu en effet qu'il était possible d'utiliser du XML, seulement je travaille sur Mysql et il me semble que ce n'est pas possible avec ce SGBD, à moins que je me trompe? J'ai besoin d'un SGBD gratuit malheureusement. A moins qu'il y est d'autres SGBD gratuit qui puisse faire ceci?

il faut comprendre que plus vous allez vous éloigner du pur relationnel, moins les performances seront bonnes. Donc, les solutions par meta modèles, ne doivent pas porter sur toutes les données, mais sur quelques unes l Que le méta modèle soit en table ou en xml ce sera juste les capacités du SGBDR et notamment ses qualités, qui feront la différence. En ce qui concerne MySQmerde, comme c'est le plus pourri au niveau des performances, je vous souhaite bon courage !

Plus sérieusement, vous n'avez pas besoin d'un méta modèle. Il suffit de faire une analyse pour se rendre compte que vous aurez au plus une douzaine de critères différents modulables, du genre :
public visé
type de place / nombre
type de salle

parce que sinon vos requêtes d'interrogation vont être très complexes à écrire de manière automatique et vous n'aurez aucune performances...

A +

[StringBuilder]

La méthode que je vois de plus en plus souvent, c'est de générer les tables à la volée à partir de meta données stockées dans une base de paramétrage (ou un fichier).

Ainsi, quand l'utilisateur crée sa structure "fonctionnelle", automatiquement une table est créée avec la structure adéquate.
Ceci permet d'avoir, à mon avis, les meilleures performances, et permet aussi et surtout de pouvoir gérer des contraintes impossibles à gérer dans un modèle générique (clés étrangères, clés uniques, etc.)

La difficulté consiste surtout à concevoir le programme capable de :
- générer automatiquement les tables
- générer les modifications des tables lorsque le paramétrage évolue (et ça peut vite être coton)
- générer le code nécessaire pour exploiter les tables