i've been weeding through the documentation and the forums for a few weeks now and it remains unclear to me how best to accomplish this.
take the classic, STUDENT, COURSE, STUDENT_COURSE scenario where
STUDENT_COURSE holds a GRADE column.
so we want to be able to accomplish the following tasks:
(1) given a STUDENT, obtain a collection of COURSEs that they have taken
(2) given a COURSE, obtain a collection of STUDENTs that have taken it
(3) given a STUDENT and a COURSE, obtain the associated GRADE
(4) perform queries such as:
(4.1) get me a list of STUDENTs that have gotten a 'B' in the 'math' COURSE
(4.2) get me a list of COURSEs that have been taken by STUDENTS named 'Fred'
From what i can gather, there are (at least) three approaches, and here are some pros and cons that i can see, please correct me if i'm wrong w.r.t. if they are appropriate approaches or pros/cons:
(A) two one-to-many's
pro:
- easiest to map and understand
con:
- many-to-many isn't explicit such that traversal is more tedious
notes:
- not too concerned with "tedium" as long as items (1-4) above can be accomplished with same performance as (B) and (C) below
- can someone provide syntax examples (or links to) for (1-4) above?
(B) composite-element
pro:
- as opposed to (A), would provide explicit support for traversal of many-to-many
con:
- would have to create redundant STUDENT_COURSE definitions on both STUDENT and COURSE mapping
(C) index-many-to-many
pro:
- as opposed to (A), would provide explicit support for traversal of many-to-many
- as opposed to (B), would allow for single definition of STUDENT_COURSE entity
--------------------------------------------------------------
it seems that any non-trivial application would come across the need for an "associative entity" holding data, perhaps bi-directional traversal isn't strictly required, but i think all would benefit from an example similar to above with hbm files and code samples added perhaps to section 18 of the documentation.
|