We have a database where the PK is really a worthless field (basically it's an Identity column)
This creates a SecondaryTable problem, as an identity column to another table has no meaning to another table (with it's own identity). We have indexes that pretty much cover a PK situation. There are complicated reasons why this works better, so no complains on the setup :)
So, consider the following:
Code:
create table Primary
(
id integer not null auto_increment,
primary_field integer not null,
secondary_field integer not null,
name varchar(255),
primary key (id)
)
create table Primary_Related_Data
(
id integer not null auto_increment,
primary_field integer not null,
secondary_field integer not null,
additional_info varchar(255),
more_additional_info varchar(255),
primary key (id)
)
Technically speaking, the id fields are independent of one another, but the join fields are primary_field and secondary_field. Good old SQL would yield:
Code:
SELECT p.primary_field,
p.secondary_field,
p.name, prd.additional_info,
prd.more_additional_info
FROM Primary p,
Primary_Related_Data prd
WHERE p.primary_field = 9999
AND p.primary_field = prd.primary_field
AND p.secondary_field = prd.secondary_field
Obviously SecondaryTable will NOT work here because I'm not joining on the @Id fields (id). Personally, I think I should be able to control the JoinColumns for a SecondaryTable, and not be a "PK" - but that's neither here nor there.
Also, I do not feel there is a need to create two objects out of this either. Maybe I'm missing something - or persistence just isn't that capable, and good ol SQL still wins?
Login
FAQ
Search
