Vos avis sur la méta-modélisation (article SQLPro)

[vgaudeul]

Bonjour à tous...

tout le monde connait le célébrissime article de SQLPro à http://sqlpro.developpez.com/cours/modelisation/metadonnees/.

Je suis tenté par cette approche pour remplacer un modèle devenu intellectuellement ingérable (trop de tables, trop de relations, etc...). Mais je suis à la recherche d'opinions, d'avis et de commentaires sur cette pratique.

Obtient-on vraiment de meilleures performances en rendant son modèle totalement générique ? Quels sont les "mauvais côtés" ?

Merci pour toutes vos réponses...

Vincent :-)

[KiLVaiDeN]

En fait la version du modèle proposé par SQLPro est une version "de base".

Elle peut être améliorée; Par exemple avoir une table pour les données de type date, une table pour les données de type varchar, etc etc.. Et pas une seule table contenant toutes les valeurs en char. Ca permettrait de rajouter des index plus performants, de gérer les comparaisons sans cast, etc..

Une autre amélioration pourrait être de rajouter une table "entité", qui contiendrait une liste des champs d'une table. Ainsi, comme le dit SQLPro dans la fin de son article, tu pourrais retrouver les valeurs nulles.

Personnellement je pense que ce modèle est un bon modèle. Cependant, je trouve qu'il est adapté plus particulièrement aux entités qui ont une liste d'attributs variable. Si la liste des attributs est figée, pourquoi utiliser un modèle qui offre du "dynamisme", mais qui apporte des contraintes, notamment par rapport à la lisibilité du code, mais aussi par rapport à la "cohérence" du modèle.

Voila mon opinion, en espérant que ça réponde un peu à ta question

[vgaudeul]

merci pour ta réponse. Elle me convient particulièrement, car je suis typiquement dans le cas d'un modèle très variable. Certaines colonnes sont fixes, mais d'autres en nombre très variable peuvent être ajoutées à tout moment...

En fait, mon problème essentiel concerne l'exploitation de ces données.

Je récupère toutes mes données sous forme d'un ensemble d'enregistrements (contenant chacun en gros un nom d'attribut et une valeur). Il faut donc pouvoir "browser" cet ensemble pour obtenir toutes les informations concernant un objet. N'est-ce pas pénalisant finalement ?

Et si je crée des vues avec des "join", je peux obtenir les mêmes informations sous forme de colonnes. Mais est-ce performant ??

Merci pour ton aide !

Vincent

[Médiat]

Sans rentrer dans les détails techniques et/ou de performance, ce qui me gène le plus dans cette modélisation, c'est que le modèle du métier de l'entreprise n'est pas capturé par le modèle de données, mais par le contenu de certaines tables, ce qui le rend beaucoup plus sensible aux dérives et non lisible.
Il va de soi, que dans une optique progiciel, cet argument tombe du fait que, de toute façon, ce n'est pas le modèle du progiciel qui capture le métier spécifique de l'entreprise, mais le paramètrage du progiciel.

PS : je ne sais pas comment gérer le NOT NULL d'un attribut (on ne peut plus dire colonne) dans le cadre de la modélisation par méta-données ?

[fadace]

Je rejoins vos divers points de vue. Dans la pratique, j'associe ce type de modélisation à des parties bien précises de mon modèle : les tables de type ou de libellé sont des candidates adéquates.

[KiLVaiDeN]

En comparaison avec un accès direct aux données par le biais des colonnes, la jointure sera toujours plus lente. Je ne pense pas cependant que ce soit pénalisant.

Il se peut même que dans le cas d'un grand nombre de données, l'accès soit plus rapide, car sans connaitre la technique interne des SGBDR, je suppose que l'espace disque est mieux utilisé dans le cas de tables plus "éclatés", et donc l'accès aux données spécifiques s'en trouve amélioré. Pour peu qu'un bon DBA place ces données de telles façons qu'elles soient accessibles de manière performante, ça peut sacrément dépoter en comparaison à une table qui contient 50 colonnes par exemple. Après, je ne suis pas suffisament callé pour répondre à la place d'un DBA, et peut-être qu'il te dira qu'une table de 50 colonnes peut aussi être optimisée d'une telle façon.

Un autre avantage au niveau des performances que je vois serait au niveau de la génération de statistiques, mais ça dépend quand même du type de statistiques, et je ne préfère pas dire de bêtises.. Mais l'accès à une table unique pour un type de données me parrait puissant pour faire des calculs, encore une fois en me basant sur ma première hypothèse qui est peut-être fausse!

Je suis d'accord sur le fait que ce modèle de données ne reflète pas de manière nette le modèle métier, et donc il en résulte une complication qui n'est peut-être pas justifiée dans la pratique; Comme il a été dit, je pense que cette technique est vraiment valable dans le cas spécifique d'une entité ayant un grand nombre d'attributs variables et qui est vouée à évoluer.

Une dernière chose par rapport aux champs NOT NULL : en introduisant une table "entité" qui listerait les champs et les types d'une entité, on pourrait faire une jointure de type (+) et récupérer tous les champs de l'entité, en ayant NULL si le champ n'existe pas; A tester, j'ai utilisé un tel modèle de données il y a longtemps, mais je ne me souciais pas des valeurs NULL, car seules les valeurs existantes m'interessaient ! Peut-être que si une valeur est "obligatoire" ou "à tester", il vaudrait mieux l'inclure dans la table de base, c'est une interrogation légitime, et je pense qu'il s'agit après d'un choix personnel, ou bien d'une obligation liée à une contrainte du SGBDR.

[fadace]

C'est pas dit : une petite table de type, par ce procédé, peut se retrouver systématiquement en mémoire/buffer pool et donc être boostée...

[SQLpro]

Quelques améliorations peuvent être apportées au sujet de mon article. Par exemple l'emploi d'un type VARIANT présent par exemple sous MS SQL Server.
Une autre façon de faire est d'utiliser ce principe pur chacune des tables qui en éprouve le besoin et non pas toutes les tables de la base. En effet en pratique il est rare que l'on ait besoin de plus d'un ou deux méta modèle "allongeant" la table cible.
Dans ce cas on créera autant de tables de méta modélisation (a l'exception de la table des type SQL) que de table candidate.

Enfin, l'utilisation de la transformation "PIVOT" présent sur certains SGBDR permet de faire croire à l'utilisateur qu'il n'a qu'une seule table avec toutes les colonnes, notamment en créant une vue de mise à plat. Et si le besoin s'en fait sentir, elle peut être indexée si le SGBDR l'accepte (MS SQL Server encore....)

A +

[Médiat]

Envoyé par SQLPro

C'est vraiment genre de connerie qui n'ont rien à faire au sein du SGBDR car cela peut être fait au niveau client...

Voici ce que j'écrit sur MS SQL Server 2005 à ce sujet :

Citation:
1.8 Opérateur PIVOT / UNPIVOT

L'horrible, mais traditionnel opérateur PIVOT, bien qu'absent de la norme SQL fait son apparition dans SQL Server 2005 afin de permettre de réaliser des tableaux croisés. Il s'agit simplement d'une astuce cosmétique pour présenter des données avec de nouvelles colonnes dont les noms sont extraits d'une des colonnes de la requête.

....

PIVOT n'existe pas dans le langage SQL. C'est un truc à la con de pure cosmétique pour les zozos qui bidouillent en acces...

As-tu changé d'avis sur PIVOT ?