Méta-donnés - type de données

**Dimitri69** · 23/10/2010, 11h23

Bonjour,

C'est avec beaucoup d'intérêt que j'ai lu l'article sur la technique des méta données, par SQLPro.

Je vais pouvoir mettre en application ce principe pour un projet personnel.

Cependant, il me manque une précision. J'utilise actuellement MySQL (on me conseillera peut-être d'en changer, mais ma question ne porte pas directement sur ce SGBB) et, lorsque je créé un champ dans une table, je choisis un type (char, varchar, int, text, etc.)

C'est ce point que je ne comprends pas dans la technique des méta données.

Je dois pouvoir ajouter, dynamiquement, des champs à une table, et l'utilisateur devra choisir de quel type il s'agit. Ce pourra être une date, un nombre, mais aussi un texte pouvant être important (longtext).

Or, et si j'ai bien compris, un seul champ recevra ces différents types de valeurs (CRP_VALEUR dans l'article). Il est dit qu'un type acceptable, pour ce champ, serait un char(32). Dans mon cas, il me faudrait un longtext. Sachant que, parfois, l'enregistrement pourra être un nombre.

Quid de l'optimisation d'un tel schéma ? C'est ce point que je n'arrive pas à comprendre, à moins que quelque chose m'ait échappé ?

Qui peut m'apporter une aide à la compréhension de ce point ?

Merci par avance.

**Waldar** · 26/10/2010, 17h27

Je pense qu'il manque un chapitre sur les précautions à prendre avec le méta-modèle.

Rajouter des informations dynamique sur des tables de références, ok pourquoi pas, ça va fonctionner.

L'appliquer à une table de faits c'est se tirer une balle dans le pied, je suis persuadé que ça ne tiendrait pas la montée en charge.

Je vous invite à lire ce blog (en anglais) :
http://www.simple-talk.com/opinion/o...ces/bad-carma/

La modélisation discutée dans ce sujet n'avait rien à voir avec celle de SQLPro, mais l'idée de départ était la même.

**SQLpro** · 26/10/2010, 17h45

ca marche parfaitement bien, même lors des montées en charge. En dépit d'ailleurs de ce que mon ami Stéphane Faroult montre dans sa vidéo sur Oracle en matière de worst practice :

Mais il y a quelques secrets :
1) créer autant de tables de données qu'il y a de types SQL (donc une table pour les DATE une pour les nombres, une pour les alpha....)

2) indexer correctement les méta et les valeurs

2) écrire des requêtes "sargeable" même lorsqu'il y a plusieurs critères à rechercher (en utilisant notamment les CTE avec des UNION ALL

A +