Discussion :

[dorian53]

Bonjour,

Voici une problématique de conception sur un SGBD classique reposant sur modèle de données relationnel (pas de NoSQL).

Comment stocker / requêter / afficher un nombre inconnu de données de type indéfini sur un sujet commun « SC » au sein d’un progiciel de gestion de « SC » exploité par X clients ?

Pour mieux représenter et expliquer les choses, veuillez-vous appuyiez sur les schémas que j'ai essayé de modéliser dans la pièce jointe "exemples.png".

Quelles critiques, retours sur expérience, proposition pourriez-vous partager sur cette question ?

Merci,
Dorian

[montesq]

Voici 2 pointeurs traitant du sujet:
- http://sqlpro.developpez.com/cours/m...n/metadonnees/
- http://www.developpez.net/forums/d98...-meta-donnees/

[dorian53]

Cela fait partie des solutions que je propose mais justement, je trouve que ce principe de meta-données à ses limites...

Au niveau du CRUD, cela multiplie tous les traitements (c'est trop lourd niveau charge). Il faudra toujours exécuter x requêtes par colonnes.

De plus le requêtage devient ingérable, il faut ré-écrire un moteur SQL.
L'exemple du cours ne présente que des "SELECT" basés sur des conditions "AND" : simples.
Essayez désormais de gérer une requête conditionnée par des "AND" et des "OR"... Il faut analyser la chaîne de requête pour savoir combien de valeurs doivent être retournées afin d'obtenir un enregistrement valide.

Code :

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

SELECT ... WHERE .... AND (.... OR ...)

Une sous-requête impose la gestion d'un COUNT() >= 2. Un vrai casse-tête qui donne l'impression d'écrire un moteur SQL.

Bref, voici pourquoi je souhaiterais m'orienter vers la solution 3. Une table par client ?

Qu'en pensez-vous ? Avez-vous des remarques, des mises en garde sur ce genre de solution.

Merci

[montesq]

Bref, voici pourquoi je souhaiterais m'orienter vers la solution 3. Une table par client ?

Qu'en pensez-vous ? Avez-vous des remarques, des mises en garde sur ce genre de solution.

Chaque système a ses avantages, ses limites et ses inconvénients, il suffit simplement d'en avoir conscience et de choisir la bonne solution en fonction de tes besoins (comme d'hab quoi :p)...

Dans la solution 3:
- à chaque fois que tu as un nouveau client, il faut refaire du développement pour adapter la nouvelle table à ses besoins
- à chaque fois qu'un client a besoin d'un nouvel attribut, il faut refaire du dév aussii
- impossible (sauf par convention de nommage) de consolider des informations sur l'ensemble des clients

[dorian53]

- à chaque fois que tu as un nouveau client, il faut refaire du développement pour adapter la nouvelle table à ses besoins

Il n'y a pas de développement, de la même manière que l'on crée un champ dans le contexte "meta-donnée" on crée une colonne à notre table. On peut très bien imaginer des interfaces utilisateur pour gérer ça.

- à chaque fois qu'un client a besoin d'un nouvel attribut, il faut refaire du dév aussii

Idem que la réponse précédente.

- impossible (sauf par convention de nommage) de consolider des informations sur l'ensemble des clients

Qu'entends-tu par consolider ? Chaque client a son propre jeu de données.
Il peut y avoir des champs/colonnes qui ont le même rôle, mais dans ce cas elles sont identifiées par un "flag" dans une table de paramétrage.
Par exemple :
La référence = colonne1 chez client 1
La référence = colonne5 chez client 2

Non ?

[montesq]

Il n'y a pas de développement, de la même manière que l'on crée un champ dans le contexte "meta-donnée" on crée une colonne à notre table. On peut très bien imaginer des interfaces utilisateur pour gérer ça.

Oui mais au niveau de ton application, il faut bien que sur le formulaire de saisie tu renseignes les champs qui sont à ta disposition en base de données et de quelle façon les remplir, non?
A moins que tu n'aies pas de partie applicative et que tu interroges directement la base via un client SQL ou encore que ton application ne fasse que de la lecture seule et dans ce cas là tu pourrais éventuellement te permettre d'afficher toutes les colonnes de ta table (mais quid par exemple des libellés des colonnes qu'il faudrait afficher?)

Qu'entends-tu par consolider ? Chaque client a son propre jeu de données.
Il peut y avoir des champs/colonnes qui ont le même rôle, mais dans ce cas elles sont identifiées par un "flag" dans une table de paramétrage.
Par exemple :
La référence = colonne1 chez client 1
La référence = colonne5 chez client 2

Non ?

Oui, on peut faire ça mais en terme de performances c'est moins bien d'aller taper dans n tables qui ont un attribut en commun que dans une seule table... Mais encore une fois chacun a ses avantages et chacun ses inconvénients!
Donc, challenge bien tes besoins en terme de flexibilité avant de décider quel modèle adopter.

[dorian53]

Oui mais au niveau de ton application, il faut bien que sur le formulaire de saisie tu renseignes les champs qui sont à ta disposition en base de données et de quelle façon les remplir, non?
A moins que tu n'aies pas de partie applicative et que tu interroges directement la base via un client SQL ou encore que ton application ne fasse que de la lecture seule et dans ce cas là tu pourrais éventuellement te permettre d'afficher toutes les colonnes de ta table (mais quid par exemple des libellés des colonnes qu'il faudrait afficher?)

Ok je comprends, de la même manière que les flags, tout cela est stocké dans des tables de paramétrage.
Comme expliqué plus haut, je pense que le vrai problème de ces modèles "meta-donnée" est le requêtage si l'on ne possède pas les enregistrements sous forme de ligne (avec les valeurs en colonne).
C'est pour cette raison que je n'en veux plus car après un mis en place cette solution sur projet j'ai désormais conscience de la difficulté et de la lourdeur des traitements que cela engendre.

Oui, on peut faire ça mais en terme de performances c'est moins bien d'aller taper dans n tables qui ont un attribut en commun que dans une seule table... Mais encore une fois chacun a ses avantages et chacun ses inconvénients!
Donc, challenge bien tes besoins en terme de flexibilité avant de décider quel modèle adopter.

Dans mon cas, on exploite les données que client par client (une seule table à la fois).


Merci pour ta participation sur le sujet, comme souvent je vois bien qu'il n'y a pas de solution magique, tout dépend du besoin. Je pense néanmoins tester la 3ème solution pour me faire une idée et avoir un retour d'expérience.