Discussion :

[lahdeb]

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

[bstevy]

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 ?

[lahdeb]

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

[mnitu]

... 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".

[lahdeb]

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

[mnitu]

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.

[lahdeb]

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

[mnitu]

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.