Discussion :

[boubil]

Bonjour

Je m'interroge sur la bonne structures de tables à mettre en place dans ma base de données.

Actuellement ma base de donnée contient entre autres une table pour gérer des fichiers.
Cette table contient des infos classiques :
- ID
- nom du fichier
- extention
- type de fichier
- référence au propriétaire du fichier

La référence au propriétaire du fichier est une référence externe vers la table des personnes.


J'ai besoin de complexifier mon application et désormais un fichier n'est plus forcement attaché à une personne mais peut être attaché à un autre objet de ma base de donnée comme par exemple
- une inscription
- une animation
- une salle
- une exposition

Comment puis-je gérer cela ? Je souhaite bien évidement conserver au maximums les contraintes d'intégrités et j'aimerais coté applicatif garder un code le plus générique possible.

Un fichier ne peut être lié qu'a un seul autre objet (une personne, une inscription,...)
Par contre un objet (une personne, une inscription,...) peut avoir plusieurs fichiers.

Mon idée est d'utiliser une table de jointure pour chaque objet
Ex
table fichier_personnes ( reffichier, refpersonne) avec unicité sur le fichier
table fichier_inscription (reffichier, refinscription) ...

mais ceci ne me garanti pas l'unicité du reffichier entre toutes les tables de jointure et ne me permet pas de cascader les suppressions

Je vous remercie d'avance de vos éclairages sur la question.

Nathalie

[aieeeuuuuu]

Bonjour,

Votre idée est bonne.
Il faudra passer par des déclencheurs (insert et update) sur chaque table associative pour assurer l'intégrité (unicité du fichier) ainsi que pour gérer vos suppressions en cascade.

Une alternative est de mettre en place un héritage. En gros, ajouter une table mère "objet". Chaque table fille (personne, inscription, animation,...) héritera de cette nouvelle table : la clef primaire des tables filles sera également clef étrangère vers la table "objet".
La table fichier référencera la table objet.
Vous pourrez alors mettre en place la suppression en cascade, par contre il faudra ajouter des déclencheurs sur les tables filles pour assurer l'intégrité des objets : un personne ne peut également être une inscription,...

plsu de détail sur l'héritage ici : http://sqlpro.developpez.com/cours/m...n/heritage/#L5


Attention toutefois à la suppression en cascade. Elle simplifie certes les choses, mais il faut avoir conscience de sa présence. Lorsqu'on supprime une personne, on ne s'attend pas forcément à supprimer des fichiers de façon implicite...
A utiliser donc a bon escient (suppression en cascade des détails d'une commande lors de la suppression d'une commande, suppression des adresses ou téléphones rattachés à une personne lors de la suppression de la personne,...)