Gestion des champs dynamiques

Bonjour tout le monde,
J'aimerai avoir vos idées à propos d'un petit défit:
Pour un projet de migration , j'ai comme mission de refaire le modèle de donnée.
nous avons une Bd pour une application web , il y a un champs dans l'application qu'on saisi dynamiquement, ce champs s'appelle champ personnalisé(pour un magasin) càd se remplis selon le besoin , le problème c'est que le type de champs est dynamique càd on peut par exemple saisir une surface pour le magasin , dans ce cas il sera un entier , ou une date d'ouverture/fermeture (type date) , ou immatriculation (chaine)..., je veux savoir comment gérer ce volet dans mon nouveau modèle , sachant que nous ne savons pas quels sont les champs dans nous aurons besoin d'avoir.
j'ai pensé à créer une table champs personnalisé avec comme attributs tous les types qu'on peut avoir (mais ce n'est pas pratique)
ça serai plus délicat si je peux ajouter un attribut champ personnalisé dans ma table magasin , mais il reste le pb des types.
Merci à vous
cdt

est ce que le mieux ne serait pas de créer une colonne varchar ? qui en soit peut contenir un peu tous les types de données.

Et pourquoi pas rajouter une colonne à coté pour identifier le contenue
un truc du genre :
"2015-05-11" "Date d'ouverture"
"1000" "superficie"
...

vous avez une liste exhaustive du type d'information qui peut etre renseignée ou c'est vriament à la tete du client ?

Merci bstevy,en fait j'ai déjà pensé à la colonne de type varchar , mais je veux vraiment la laisser comme dernière, solution j'aimerai savoir s'il y a possibilité de créer un type dynamique.
pour la liste des valeurs, oui ça change selon l'information que veux voir le client , en fait il était très judicieux de créer une base de donnée plus précise avec tant de champs que nous voulons avoir sur un magasin , mais "les décideurs" je ne sais pas moi pourquoi ils compliquent la tache mais bon , c'est la demande client.
Merci encore

Citation:

---

Envoyé par lahdeb

... sachant que nous ne savons pas quels sont les champs dans nous aurons besoin d'avoir.
...

---

Cela veut dire que l'analyse est incomplète. Il n'y pas grand chose à faire à part de finir l'étape d'analyse d'abord sinon c'est de la "programmation orientée maintenance".

ce que je voudrais dire par ne nous savons pas quel champs seras demandé , c'est que dans l'application on définit ce dont nous avons besoin selon le besoin qui change ...
exemple : nous voulons savoir les raisons de la fermeture du magasin : on pourra renseigner sa date de fermeture , le nombre d'employé, la distance qui le sépart d'une zone critique.....
merci

Cette zone "dynamique" c'est soit un sort de post-it: on écrit un texte qu'on affiche quelque part et ça c'est tout, soit une analyse inachevée.
Dans le premier cas comme c'est un "post-it" le type de la zone est forcement du texte et bien se poser des question de type compter le nombre des employées ou trouver le magasin situé à la distance plus grande d'un repère ne se pose pas.
Dans le deuxième cas l'analyse devrait identifier tous les informations ayant une signification pour les entités impliqué par les besoins de l'application.

Merci mnitu, actuellement la demande utilisateur c'est de pouvoir renseigner un champs dynamique (de type dynamique) dans la nouvelle base de données,
j'ai déjà posé la question si les champs à renseigner sont limités, la réponse était que ces champs changent selon le besoin de renseignement qu'on veut voir sur un magasin donné.
Merci

Oui les clients demande parfois n'importe quoi. Dans ce cas c'est une zone de type texte et basta.
Mais insister à leur expliquer quelle est la différence entre stocker une information qui ne sera utilisable qu'au niveau d'affichage vers celle utilisable dans une analyse.

Donc il n y a pas moyen en "général" sous oracle qui permettra de faire un type dynamique?
Dans ce cas je vais revenir au format texte :/.
Merci pour tout

Bonjour,

Les remarques concernant le problème d'analyse etc .. sont évidemment pleines de bon sens, mais si je comprends bien, ce que recherche lahdeb ressemble fort a ANYDATA / ANYTYPE, non ?
(il y a des tutos a ce sujet sur Developpez.com d'ailleurs)

@+
;)

merci Sunchaser,
en fait c'est ce qu'on utilise actuellement dans le web , ce sont des des données de type anydata/anytype mais dans le but d'un projet décisionnel je suis entrain de récupérer ces données crées dans le web pour ressortir des rapport , du coup et vu les difficultés trouvé avec ces types, je cherches à combler cela par une autre solution.
cdt

Bonjour à tous , je reviens vers vous pour expliquer un peu le pb que je rencontre:
en fait , le pb du type de données dynamique je l'ai combler en créant un champs texte dans mon datamart qui va contenir tout les types .
le problème c'est que dans mon outil de reporting il faut que j'affiche des graphe basés sur les donnée dynamique du type (num,date..), l'outil me permet de convertir le texte en num , mais vu la liste inconue est exhaustive des données dynamique je ne peux pas toutes les convertir dans l'outil de reporting.
donc il faut que je trouve un moyen de créer un type dynamique càd , lorsque je récupère les données depuis la BD relationnelle vers mon datamart (crée sous oracle) il faut que le champs soit reconnu comme num ou varchar ou date..
exemple:
pour un magasin , on renseigne dans la BD relationnelle une donnée dynamique date d'ouverture de type date,
pour un autre magasin , on renseigne une autre donnée date de fermeture (d’accréditation , de mise en marche ...) de type date, on renseigne aussi sa surface de type num , le nom de la société mère de type varchar , on peut aussi renseigner une donnée de type liste....
voilà la table que je veux ressemble à cela

Id_Champs	Nom	Valeur	Id_magasin
11	Surface	400	1125
12	Date_ouverture	12/04/2014	1125
14	Date_fermeture	12/017/2014	1256
15	Qualité	moyen	1258

ce n'est qu'un exemple de valeur qu'on peut avoir on peut encore avoir d'autre valeur ...
merci

Les demandes post-it, bloc note et autre fourre tout sont récurrentes dans les expressions de besoin
Il me semble que le rôle de la maitrise d'œuvre est de militer contre.

Parmi les arguments défavorables, on peut citer (liste non exhaustive) :
- indexation impossible d'où temps de réponse rédhibitoires
- données saisies sans contrôle, ni structuration, qui n'ont le plus souvent de sens que pour le rédacteur
(ex : abréviations propres au rédacteur)
- aucune garantie d'unicité
- portabilité impossible
- encombre la base de données pour une utilisation souvent marginale ou requiert des colonnes de type varchar ou longvarchar,
qui complexifient le code et sont source de dégradation des perfs (déplacement physique des lignes quand la longueur augmente)

Un projet de migraion est justement l'occasion de se débarrasser de ces colonnes fourre-tout qui sont contraires aux principes d'une base de donnée relationnelle

Après il ne faut pas être sectaire non plus. Les spécifications qui évoluent vite ça existe aussi, et on n'a pas toujours le temps de faire un cycle de V.
Quand j'ai travaillé chez un grand distributeur sur internet, ils avaient une table de produits avec quelques millions de références, et chaque produit a ses caractéristiques.
Et comme on ne sait pas à l'avance ce qu'on va vendre, elles sont impossibles à figer.

La colonne texte effectivement répond au besoin de façon basique, mais vous en avez vite trouvé la limite.
Essayez de vous inspirer de cet article de SQLPro :
http://sqlpro.developpez.com/cours/m...n/metadonnees/

C'est du SQL-Server, mais rien de non transposable à Oracle.
Et au moins vos typages seront respectés.

Merci Waldar :)

Citation:

---

Essayez de vous inspirer de cet article de SQLPro ...

---

J'avoue être incapable de lire attentivement ce type d'article jusqu'au but. Ca me rappelle toujours une vielle histoire
Bad CaRMa

C'est différent quand même entre mettre tout le MPD d'une application dans une seule table DATA et avoir du paramétrage dynamique sur une caractéristique d'un objet réparti sur quatre / cinq tables selon les types de données.

Mais cette histoire est quand même intéressante et toujours à garder dans un coin de l'esprit.

Comme je l'ai déjà avoué je n'ai pas lu tout avec attention, mais ce paragraphe à la fin me semble à semer le doute y compris à l'auteur.

Citation:

---

Mais il ne faut pas oublier de bien indexer un tel modèle !

En revanche s'il faut gérer l'intégrité référentielle, cela est possible à condition que la base accepte la pose de trigger. En effet il suffit de placer dans les tables méta caractérisées, un trigger qui supprime les références de ligne en cascade dans la table T_DONNEE_DON.

---

D'autre part j'essaye de m'imaginer la réaction d'un ingénieur travaillant dans l'industrie de l'automobile par exemple, à qui on a demandé de fabriquer une nouvelle voiture mais pour laquelle le choix concernant les sous-système de roulement sera définie de la façon suivante:
- pour l'instant nous ne savons pas bien par où cette voiture devrait rouler: ça pourrait être l'autoroute mais peut-être le dessert ou la montagne ou le marais ou le sable ou bien dans l'eau ou sur les théâtres des opérations militaires ou dans les compétitions de formule 1, etc.