Moi je pense que nous sommes devant le cas de figure typique où il faut faire un usage massif de la technologie XML et des transformations XSL....
Si tu veux du générique et pourtant structuré alors il faut utiliser le couple XML/XSL....
:fessee:
Version imprimable
Moi je pense que nous sommes devant le cas de figure typique où il faut faire un usage massif de la technologie XML et des transformations XSL....
Si tu veux du générique et pourtant structuré alors il faut utiliser le couple XML/XSL....
:fessee:
Salut,
j'ai un petit problème ... à un outil peut être associé plusieurs documents. Un document est caractérisé par :
- son nom
- son type (spec, manuel utilisateur, ...)
- le lien vers le doc
- la langue dans laquelle il existe.
Dans le cas du modèle avec les tables produit-clé-valeur, il faudrait qu'à la table clé, j'ajoute un champ type_cle qui donnerait le type de la clé, par exemple pour une langue, ce serait varchar. Il faudrait également que je crée un type tDoc qui contiendrait les attributs nomDoc, typeDoc, lienDoc, langue... est-ce bien ça?
Il faudrait aussi que j'autorise l'utilisateur à créer ses propres types, non? est ce aussi dangereux que si je laissais à l'utilsateur la possibilité de créer ses propres tables (comme je voulais le faire au début) ??
Au fait, comment ça marcherait avec le xml, xsl? Parce qu'il y a une notion d'arbre dedans non? je ne vois pas trop comment faire avec ça...
Merci beaucoup!
Liichiii
Oui c'est ca! je repète tu dois faire une autre table pour document qui contient la clé étrangere (FK) sur l'id de la clé de la table produit ou outils (je sais pas comment tu l'as appellé.
Un petit conseil, si tu as le temps fait un schéma de BDD avec un soft telle que visio ou DBDesigner et ensuite poste le, C'est quand meme plus simple pour comprendre:lol:
A+
Salut Shiftane,
tu me dis "oui c ça!" mais tu proposes une autre solution que la mienne. Moi je proposais de créer des types, par exemple pour document, créer le type tDoc qui contiendra les attributs nomDoc, lienDoc, typeDoc, langue. Et toi tu me dis de créer une table à part pour document. Or le problème est qu'il y a d'autres caractéristiques dans ce cas, comme par exemple l'environnement de développement. Celui-ci est caractérisé par le nom de l'environnement et la version. D'après ma solution, je créerai un type tEnvDev avec comme attributs nomEnvDev et versionEnvDev. Selon ta solution, je créerai une table envDev c ça?
Le problème est que si l'utilisateur veut par la suite ajouter des caractéristiques qui contiennent plusieurs attributs (comme document et envDev), dans mon cas, il devra créer un type et dans le tien une table... et tu m'as dit que ct pas bien de laisser à l'utilisateur la possibilité de modifier le modèle... qu'en penses tu ? est ce que c mieux qu'il ait juste la possibilité de créer ses propres types ?
Merci
Liichiii
En faite j'avais pas capter, le matin tot comme ca c est pas facile :D .
Bon je comprend en faite pour chaque entité pouvant avoir des données supplémentaire, tu créé une table annexe lié avec une clé étrangère sur la table avec chaque fois ta variable, ton type, la valeur.
Comme ca tu change que cette dernière pour chaque utilisateur...
Je sais pas si j'ai répondu ?