J'ai besoin d'aide pour concevoir ma base de données oo pour gérer plusieurs types de relations

Question

Je crée actuellement un programme de base de données en Java et je suis un peu coincé avec le design. c'est assez simple jusqu'à ce que je frappe la partie où il y a plus de 40 différents types d'activités qui peuvent aller de la vente de livres à des tutoriels aux apparences radio/tv. chaque type d'activité a un ensemble différent de propriétés, telles que les documents nécessaires, le nom du type d'activité, etc.

je l'ai considéré juste dur coder chaque activité. J'ai également envisagé de généraliser les types d'activités dans des sous-classes telles que les activités basées sur la présence et les activités basées sur les achats, mais cela limite l'extensibilité du système. et je dois aussi considérer les classes d'objets. aurait à faire 40 classes différentes qui tous prolongent l'activité? J'ai envisagé de créer une table activity_type mais je ne sais pas comment j'implémenterais les types d'activités dans la partie java.

ma question est: comment devrais-je concevoir mon système?

Answer 1

Vous pouvez lire sur le Entity-attribute-value model.

Answer 2

Est-ce que vous devez rechercher/trier en utilisant toutes ces propriétés supplémentaires, à savoir doivent-ils être des champs SQL? Si ce n'est pas le cas, vous pouvez avoir vos propriétés de base en tant que champs indexés, et les autres champs d'un blob (par exemple un document XML) qui est stocké dans un champ de chaque table SQL.

Answer 3

Une autre approche que vous pourriez envisager est d'utiliser des métadonnées pour vos objets. Vous pouvez avoir une table d'activité avec toutes les informations de base. Ayez ensuite une table activityattribute qui stocke toutes les métadonnées pour chacun de vos objets. Cela rend très facile la création de nouveaux objets avec un minimum de code. Mais cela rend définitivement l'interrogation plus difficile.

Lorsque vous appliquez la création juste des modèles qui contiennent tous les attributs qui doivent être appliqués pour l'objet que vous créez.

Answer 4

est ici un point de vue de coder en dur les activités vs les stocker dans la base de données:

Si vous coder en dur les activités dans votre code, vous ne pouvez pas ajouter (ou supprimer ou modifier) ​​une activité sans recompiler et redéployer votre code. Mais lors du codage, vous connaissez toutes les activités possibles, donc votre code peut les gérer tous.

Si vous stockez les activités dans la base de données, vous pouvez facilement ajouter, supprimer ou modifier une activité. Et vous pourriez permettre aux utilisateurs (peut-être seulement aux utilisateurs ayant certains rôles) d'apporter des modifications aux activités. Mais votre code ne peut pas nécessairement gérer correctement une nouvelle activité.

Donc, Je voudrais baser mon choix sur si le code peut gérer les changements dans la liste des activités. Si c'est le cas - par exemple, les activités ne sont affichées, ou c'est juste CRUD avec des choix d'activités dans les listes déroulantes - alors je pencherais vers l'approche de la base de données. C'est parce que vous pouvez changer les activités dans la base de données sans recompiler votre code.

Answer 5

Tenir compte de ce modèle

Type-of-Activity 1 <----> * Type-of-Things-Needed 
    1       1 
    |       | 
    *       * 
Activity   1 <----> * Things-Needed 

Vous devez vous assurer que seules choses nécessaires peuvent être ajoutées à une activité qui sont des type de-choses-needed associée à type de-Activité de l'activité .

Answer 6

Il existe un modèle disponible. Jetez un oeil à this question/answer; décrit le modèle d'observation.Il utilise cinq tables et peut être implémenté dans un SGBDR "standard". Une entité peut avoir n'importe quel nombre de propriétés personnalisées (observations).