Discussion :

[okydo]

bonjour je commence avec hibernate et je me posais une question :

comment peut on crée un type personnelle?
en clair, je veux créer un attribut de type Adresse ( qui comprend plusieurs champs String et autre : residence, numero [String], type de rue [String],rue [String], Ville <many-to-one class="vile">,...).
Si je ne l'utilisai que dans une table je ferai un component je pense que ca sert a ca. mais la j'ai plusieurs objets/tables qui utiliseront ce type d'attribut,(des Personnes, des entreprises, des secrétariast, ...). j'ai plusieurs solutions :
- répéter le "component" dans chaque table
- créer une table adresse avec un lien unidirectionnelle pour ne pas y trouver de clé etrangere.
- autre comme usertype mais la faudrai m'expliqué car dans la doc ils ne sont pas très documenté

Laquelle vous parait la plus aproprié

[Pikwik]

En fonction de ta relation tu fais un many-to-one ou un bag, et une table pour la class Adresse. Cela me parait beacoup plus simple et bien plus logique. Globalement, mieux vaut plusieures tables petite qu'une grosse où tu ajoutes plein de champs.

[okydo]

merci mais j'ai oublier de precisé que je vais avoir plusieurs catalogues donc le problème est que j'aurai 1 table adresse par catalogue sinon j'aurai une seule table avec l'ensemble des adresses de toutes mes applications( 1 application = 1 catalogue)

[manblaizo]

Bonjour,
A mon avis, la première solution (component dans chaque table) est meilleure en termes de performance. Sauf si un objet Adresse possède une identité propre dans ton modèle, je ne vois pas pourquoi tu aurais besoin de définir une table spéciale pour contenir toutes les adresses. Or, si une adresse n'a de l'intérêt que lorsqu'elle appartient a une Personne ou Entreprise, le mieux c'est d'enregistrer les informations d'adresse dans la même table que Personne ou Entreprise. Cela te permet d'avoir une base de données dénormalisée de ce point de vue et d'éviter des "inner join" pour charger l'adresse chaque fois que tu charge une personne ... En tout cas, tu devrais décider en tenant compte des performances et en considérant ce qu'est véritablement l'importance d'une entité adresse par rapport aux autres entités dans ton modèle.
a++

[OButterlin]

D'accord avec manblaizo, la pluspart du temps tu te compliques la vie avec les tables adresses séparées.
Il ne faut pas oublier les contraintes liées, dans le genre :
- une adresse référencée dans une facture émise ne doit plus pouvoir être changée
- 12 rue des Tulipes représente la même adresse que 12 RUE DES TULIPES (et on ne parle même pas des blancs supplémentaires qu'on pourrait trouver)
etc...

Donc, je trouve la solution 1 plus intéressante, au moins tu peux centraliser les contrôles au niveau de cette classe.

Ce n'est qu'un avis...
A+

[okydo]

ok je pense aussi car une table d'Adresse serai assez lourde mais il n'existe pas un racourci pour evité de devoir recopier de compomemt a chaque fois style
<property name="adressePro" type="Adresse" ou class="Adresse"/ > ??

[fr1man]

Est ce que chaque adresse pourrait appartenir à une personne, une entreprise etc en même temps ?
Si c'est le cas, tu vas duppliquer l'information dans n tables.
Qu'en penses-tu ?