>> No if one is doing with DB directly or with JDBC, the following will
>> work:
>> -- start transaction
>> INSERT INTO t_1 (name) VALUES ('name1');
>> INSERT INTO t_1 (name) VALUES ('name2');
>> INSERT INTO t_2 (name,t_1_id) select 'name1' , t_1.id from t_1 where
>> t_1.name='name1';
>> commit; -- end transaction
>
> That doesn't work unless t_1.name is unique for that table.
Please consider that this is just an example I got in reply to the
forward of "that" post.
In this *example* case t_1.name must not even need to be unique. e.g.
'name1' value could be unique, but e.g. 'name3' not necessarily (it
might be driven by the higher business logic) - or for the 'xxx_log'
table it's even required to have more rows if there are more not-unique
values - or whatever scenario.
> And if it
> is, then you have no need for t_1.id because you are effectively
> generating your own primary key.
A unique value is not a primary key. It could be a natural key. But it
might also have no meaning to the application that is writing it (or to
another one that is reading it).
Also as I mentioned a few times, I do *not decide* (like it's the case
in many many teams) how to make the database: this is why I'm using
Cayenne Modeler to do a reverse engineering of the DB model. (This is
also why I think CM with reverse engineering is the best argument of
Cayenne to get adopted)
thanks,
Joseph.
This archive was generated by hypermail 2.0.0 : Thu Apr 23 2009 - 04:58:52 EDT