Problème de mapping de ma base de données

Version imprimable

1 pièce(s) jointe(s)

Bonjour,

Dans le cadre de mon laboratoire de Java, on m'a donné un projet de moteur de jeu et j'ai fait l'analyse du projet mais je ne vois pas clairement comment mapper mon schéma via Hibernate. :calim2:

Pour les entités de jeu du moteur, je dois, plutôt que faire une table par entité, faire une table pour toutes les entités, une pour chaque attribut de chaque entité et une troisième table pour les valeurs.

J'ai cherché dans la documentation officielle de Hibernate, et je ne vois toujours pas comment mapper ça proprement malgré quelques piste (entre autres '@SecondaryTable').

J'ai réaliser un exemple des tables via Excel, pour vous permettre de visualiser le problème.

Infos sur l'exemple :

- tous les champs soulignés sont des clés primaires
- tous les champs précédé d'un '#' sont des clés étrangères
- les différents types d'entités et de valeurs sont fixé à l'avance
- une partie des attributs est fixé à l'avance et l'autre partie sera choisie par l'utilisateur (l'utilisateur doit pouvoir ajouter des informations aux entités)
- un attribut peut avoir plusieurs valeurs

Pièce jointe 143511

J'ai dû passer de la version basique à la version améliorée pour certaines raisons que je ne peux expliquer sans expliquer tout mon projet.

C'est bien sûr pour mapper la version améliorée que j'ai du mal. J'arrive à mapper les trois tables, mais comment faire pour avoir les POJO de chaque type d'entité ?

Mon but est d'arriver à ceci :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 public class entity1 extends entity { public type getAttribut1() {} public type getAttribut2() {} public type getAttribut3() {} } public class entity2 extends entity { public type getAttribut4() {} public type getAttribut5() {} public type getAttribut6() {} } public class entity3 extends entity { public type getAttribut7() {} public type getAttribut8() {} public type getAttribut9() {} }
J'ai choisi de mapper mes POJO avec les annotations (je ne sais pas si tout ce qui est faisable via les fichiers xml est faisable via les annotations, donc je préfère le préciser).

J'espère que vous avez compris ce que je veux faire, car c'est pas si simple de donner un max d'infos tout en simplifiant et réduisant le problème.

Merci de votre attention.

Tux.

20/04/2014, 11h09
OButterlin

Alors, pour être sûr qu'on parle de la même chose, tu as :
- x entités
- chaque entité à y attributs, des prédéfinis + la possibilité d'en ajouter
- chaque attribut à une seule valeur

C'est bien ça ?
Pour moi, tu as :
- 1 table Entite (id, nom)
- 1 table attribut d'entite (id, id_entite, nom, type, valeur)
Si par contre tu veux pouvoir traiter une colonne "typée" de ton attribut, on peut imaginer le modèle suivant en utilisant les discriminator
- 1 table Entite (id, nom)
- 1 table attribut d'entite (id, id_entite, nom, type)
- 1 table par type d'attribut (id_attribut, valeurTypée)

Maintenant, pour ce qui est du résultat final, tu voudrais avoir
Entity1
{
getAttribut1();
getAttribut2();
etc...
}
et là, syntax error :aie:
Comment veux-tu faire puisque tu dis que ton utilisateur peut ajouter des attributs supplémentaires
Si les attributs étaient fixes, on pourrait imaginer arriver à ce résultat via un DTO, mais en mode dynamique, je ne vois pas.

Au mieux, dans ton projet, on pourrait avoir un getter du genre getAttribut(int idx) mais pas plus...

Si tu change aussi considérablement tes tables, tu va devoir aussi changer considérablement tes classes.

Maintenant, au lieu d'avoir des trucs du genre

vitesse = entity1.getAttribut1()+entity2.getAttribut3();

tu va devoir avoir quelque chose du genre
Code:

1 2 3 4 5 Set<Attribute> attributs = entity1.getAttributes(); Attribute attribut1 = attributs.stream().filter(att -> att.getName().equals("attribut1")).findFirst().get(); attributs = entity2.getAttributes(); Attribute attribut3 = attributs.stream().filter(att -> att.getName().equals("attribut3")).findFirst().get(); vitesse = attribut1.asFloat() + attribut3.asFloat();
Je te laisse imaginer la complexité et les risque d'erreurs dans le code. En général, faire des tables comme tu le fait reviens à faire du sql dans du sql, c'est uen erreur de design. Il y a bien sûr des cas où c'est justifier, quand une modèle doit pouvoir par exemple évoluer avec des plugins ou via une interface utilisateur, mais on a rarement beson, comme tu le fait, de tout faire en dynamique.

Et n'oublie pas un truc, avec cette nouvelle complexité, en plus d'être dur à lire, tes requête SQL seront plus lentes. Là où c'était immédiat pour le gestionnaire de base de données de te retourner la liste des rows "Entité1", maintenant, cela va nécessité n*m jointures. Cela a un coût!

20/04/2014, 14h46
Tux1582

@tchize_

Citation:

Je te laisse imaginer la complexité et les risque d'erreurs dans le code. En général, faire des tables comme tu le fait reviens à faire du sql dans du sql, c'est uen erreur de design. Il y a bien sûr des cas où c'est justifier, quand une modèle doit pouvoir par exemple évoluer avec des plugins ou via une interface utilisateur, mais on a rarement beson, comme tu le fait, de tout faire en dynamique.

Je me rends bien compte que je suis en train de faire une base de données dans ma base de données, mais c'est la seule solution que j'ai trouvé pour permettre à l'utilisateur (celui qui crée les scénarios, pas celui qui y joue) de créer des déclencheurs à volonté qui modifie un attribut suite à la modification d'un autre. Ces déclencheurs seraient récursifs et serait déclenché à l'origine par une action du joueur sur un attribut d'une entité.

@tchize_

Citation:

Et n'oublie pas un truc, avec cette nouvelle complexité, en plus d'être dur à lire, tes requête SQL seront plus lentes. Là où c'était immédiat pour le gestionnaire de base de données de te retourner la liste des rows "Entité1", maintenant, cela va nécessité n*m jointures. Cela a un coût!

Yep c'est sûr, mais c'est un projet scolaire, donc les performances ne sont pas vraiment la priorité (contrairement à un projet professionnel, on est bien d'accord). Et si je veux implémenté mes déclencheurs, je vois pas trop comment faire d'autres ... Si vous avez une autre idée, je suis preneur :-)

Ma méthode me permet de mettre des déclencheurs à la fois sur les attributs fixes et les attributs personnalisés.

@OButterlin

Citation:

chaque attribut à une seule valeur

Non :

Citation:

- un attribut peut avoir plusieurs valeurs

C'est un moteur de jeu où je permet à l'utilisateur soit de créer des niveaux-scénarios, soit d'y jouer. Et vu que je veux pouvoir modifier les attributs dans une partie, il faut que je sauve toutes les valeurs possibles possibles d'un attribut et les valeurs prises dans une partie donnée. Donc je ne peux pas stocker les valeurs dans la même table que les attributs.

@OButterlin

Citation:

Comment veux-tu faire puisque tu dis que ton utilisateur peut ajouter des attributs supplémentaires

Citation:

- une partie des attributs est fixé à l'avance et l'autre partie sera choisie par l'utilisateur (l'utilisateur doit pouvoir ajouter des informations aux entités)

Je veux faire les setters-getters seulement sur les attributs fixes des entités (+- 5 attributs fixes par entités et x attributs personnalisés). Je me rends bien compte que c'est pas faisable de modifier le code de mon application directement à partir des choix et des modifications de l'utilisateur :aie:

Citation:

Si par contre tu veux pouvoir traiter une colonne "typée" de ton attribut, on peut imaginer le modèle suivant en utilisant les discriminator
- 1 table Entite (id, nom)
- 1 table attribut d'entite (id, id_entite, nom, type)
- 1 table par type d'attribut (id_attribut, valeurTypée)

Désolé, je comprends pas ton idée :?

Merci beaucoup d'avoir répondu :D