[Hibernate] Objet --> Relationel: à quel prix?

salut

j'utilise depuis qq mois hibernate3 dans différents projets, et je trouve cet outil de mapping o-r pratique, performant, ...

seulement, je suis étonné que la passage du monde objet vers le relationnel s'accompagne d'incohérences ou de mauvaise pratiques.

En particulier, le probleme des classes associations (UML): je sais le sujet a été traités sur la facon de le mapper avec hibernate, mais jamais on ne s'est interessé aux consaquences sur le schema de la bd.

Je pense en partculier aux fameuses clés primaires que l'on doit rajouter

Exemple: un panier virtuel est une classe association entre un
Produit (numP) et une Commande(numC)
on a donc Cadis(numP, numC, qte, prix)

et bien g essayé toutes les solutions avec hibernate (element composite, mapping avec les numP/numC en clé + Produit/Commande en many-to-one, equal/hashcode qui vont bien, inverse=true du bon coté, ...) la seule facon pour que ca marche bien en étant optimisé c'est de rajouter une clé primaire dans chaque classe (y compris dasn les associations), méthode que l'on trouve dasn tous les tutos et exemples utilisant hibernate:

dans l'exemple ca donne:
Cadis (numCadis, numC, numP, qte, prix)

le jour ou on abandonne hibernate, comment je justifie CA???
et vous comment vous voyez les choses?

Ou est le probleme d'utiliser des identifiants (surrogate key) ?

Citation:

---

Envoyé par Hibernate in action

Experience has shown that natural keys almost always cause problems in the long run. A good primary key must be unique, constant, and required (never null or unknow). Very few entity attributes satisfy these requirements, and some that do aren't efficiently indexable by SQL databases. In addition, you should make absolutely certain that a candidate key definition could never change throughout the lifetime of the database before promoting it to a primary key. Changing the definition of a primary key and all foreign keys that refer to it as a frustrating task.
For these reasons, we strongly recommend that new applications use synthetic identifiers (also called surrogate keys). Surrogate keys have no business meaning - they are unique values generated by the database or application.

---

J'utilisais également cette approche avant de travailler avec Hibernate pour les raisons citées.

Tu trouveras des débats sur le net défendant les 2 points de vue.

Remarque au passage :

J'ai eu l'occasion de faire une appli un peu similaire à ce que tu sembles vouloir :

Commande (id_cde, ...)
Produit (id_produit, prix, ...)
LigneCde (id_cde, id_produit, quantite)

Je ne fais pas persister mon panier, je le transforme en commande quand je décide de la valider :
Panier -> Commande
et panier.elementsPanier -> commande.lignesCde (avec transformation des objets de la collection)

oui moi aussi g toujours utilisé cette approche, rien que pour ces raisons:

Citation:

---

A good primary key must be unique, constant, and required (never null or unknow)

---

mais dans le cas des associations, je ne vois pas l'interet: a part faciliter la tache de l'orm, on peut utiliser les surogate key des tables en relation

coté performance, meme si on a plus qu'une clé primaire (au lieu de plusiuers clés composées), il faut quand meme rajouter des index sur les clés étrangères)

Citation:

---

Envoyé par mauvais_karma

mais dans le cas des associations, je ne vois pas l'interet: a part faciliter la tache de l'orm, on peut utiliser les surogate key des tables en relation

---

Si tu passes d'une association binaire (commande/produit) many-to-many à une association ternaire (commande/produit/client par exemple), tu ne garantis pas forcement le côté constant de ta clé primaire. Tu perds en flexibilité et tu dois changer la définition de ta clé primaire. Le but de ta clé artificielle est de conserver un maximum de flexibilité pour anticiper les évolutions fonctionnelles.

Citation:

---

Envoyé par mauvais_karma

coté performance, meme si on a plus qu'une clé primaire (au lieu de plusiuers clés composées), il faut quand meme rajouter des index sur les clés étrangères)

---

Je comprends pas ce que tu veux dire, tu peux formuler ca autrement STP ? Je ne vois pas l'argument contre les clés artificielles.

L'utilisation des clés artificielles est un "best practice" qui se vérifie par la pratique et lors des évolutions à apporter aux applications. Toutefois, comme je l'ai déjà dit, tu trouveras des débats sur le net à ce sujet. A toi de te faire ton opinion, la mienne est faite et basée sur mon expérience.