Yeah, you are right. I think the primary key in this case is breaking a few
rules. I think one column in this case would be sufficient, but being an
application developer and not a database developer, what do I know. I will make
some effort to push back (if even possible). But for now I need to
Your ERM is broken :-)
If the primary key in the type table has three columns, then any foreign key
referencing the type table must also have three columns. This is not a
requirement of java persistence or hibernate but of any underlying sql database.
Ask whoever created this mess to create a
The key question is: Is the table name really part of the primary key?
Because if TYPE.TYPE_ID is already (or can be made) unique it would be bad
design to use the combination of table_name and type_id as primary key because
this would violate the requirements of the 3rd NF. TABLE_NAME would be
OK. I thought my original post was pretty clear, but apparently not. So for the
purposes of this post, forget that there was ever mention of ITEM_ anything.
TYPE_TABLE:
| ++--+
| | Field | Type |
| ++--+
| | TABLE_NAME |
anonymous wrote :
| Anyone have any thoughts on how to annotate a Store object to map the
correct values?
|
Sorry, I really don't wnat to annoy you: Nobody will be able to help you
because you have not described your problem.
The point of an object relational mapping is to map the
You are not annoying me. I apparently do not have the correct vocabulary to
describe my situation adequately enough. So let me try again...
Store has a one-to-one relationship with Type. However, simply using the
following annotation is not adequate:
| @OneToOne
|
Okay. I think I'm starting to grasp what you want.
You have a store and each store is of a certain type? So you have stores of the
type department store, hardware store etc.
I guess there are fewer types of stores than stores. If that is so you do not
have a @OneToOne relationship but
Not sure if I made myself clear:
You CAN have a column in the database table_name which tells you that this type
is a type that usually refers to stores. There are just two limitations:
1.) Nothing will prevent you from assigning a type that has not Store in the
table_name column to the a
Yeah, you're right it is a ManyToOne relationship. I was thinking a Store has
one (and only one) type Type associated with it at any given time. Completely
spaced looking at it from the Type's perspective.
I think using a @ManyToOne annotation will give me what I need. After playing
around
Thanks for your response Felix. But I'm not sure you are understanding the
problem. I am not mapping Items in a store. I am mapping attributes *of* a
store. If you look in the example code I posted, there is a Type of store. What
is not in the post are other attributes like, Status, Region,
anonymous wrote :
| But I'm not sure you are understanding the problem.
|
I perfectly agree: I don't understand your problem.
That's why I said I think your ERM is broken. Your ERM should have some
explanatory structure to tell people what you are doing.
If you have just stores and no
Well, I think your ERM is broken. I think you will need three classes:
-Item, to represent the information about the item. This contains an
@EmbeddedId property of the ItemPK.
-ItemPK, the primary key of the Item class. Should be annotateed @Embeddable.
(BTW: Why do you store a TABLE_NAME.
12 matches
Mail list logo
