Hi Sarav,
Saravana Krishnan wrote:
My other doubt is, if it's a 1:1 relation between 2 tables, why not
simply merge them? What's the point in having 2 tables with 1:1
relations.
I can think of two examples:
1) You might have two entities that require address data. You don't want
to dupicate the ad
Hi,
Saravana Krishnan <[EMAIL PROTECTED]> schrieb am 08.12.2004 17:33:13:
> Hi,
> ...
> My other doubt is, if it's a 1:1 relation between 2 tables, why not
> simply merge them? What's the point in having 2 tables with 1:1
> relations.
>
> Isn't having 2 1:1 related tables like having one tabl
Hi,
I was thinking about 1:1 relations and was wondering how it could be
implemented. I settled on the conclusion that a true 1:1 relation can't
be defined in a DB. Now I see Thomas has the same conclusion too - so
one of my doubts have been cleared.
My other doubt is, if it's a 1:1 relation be
Hi Thomas,
> I am not sure if I understand the question.
you did ;-)
> (...)
> If you have a real 1:1 behaviour, you can put the foreign key on the
> other side, ...
Indeed it is a 1:1 thing. So it would be possible to switch the FK's
location. But then I'd lose the information in my "n" table
Hi Daniel,
I am not sure if I understand the question. Let me pose the question in my
own words:
You have a 1:n relation. If you save an object on the "1" side, the related
objects on the "n" side get saved.
If you are on the "n" side, why is the "1" side not saved ?
The "1" side is the side
Hello list,
one more question:
when saving, Torque's save methods just consider the associated
collections for saving, but not the single objects associated
by foreign key.
Some code:
---snip---
public void save(Connection con) throws TorqueException {
(...)
if (collSomeObjects != null)
