Hi Wulf,
Yes, you are right to say that it's a question of design.
Maybe it was not a good example.
I'll try to take another one:
You have 2 classes: Workstation and OperatingSystem. There is a 1:N relationship
between OperatingSystem and Workstation because an operating system could be installed
on many workstations, but each workstation can install only one operating system.
So, you have these 2 classes:
class Workstation { class OperatingSystem {
int wPK int osPK
String name String osName
OperatingSystem os int version
..... .....
} }
Relationnal tables are like:
Workstation OperatingSystem
----------- ---------------
wPK: integer osPK: integer
name: varchar osName: varchar
osFK: integer verion: integer
I create a osFK foreign key in the relationnal table Workstation to have the
relationship between these 2 tables. This is, I think, a proper way to do this, right?
OK, now my questions about this example and OJB:
1) [OJB question] do you need to create an osFK attribute in Workstation class?
2)[design question] what do you think if I put a wFK in the operatingSystem table
instead of the osFK in Workstation table? Does it work with OJB?
Thank you
Regards
Sylvain
-----Message d'origine-----
De: Wulf Wechsung [mailto:[EMAIL PROTECTED]]
Date: mercredi, 11. d�cembre 2002 19:53
�: OJB Users List
Objet: AW: Newbie question: associations
Hi Sylvain,
> For OJB, to do an association between Person and Address you need a foreign key
>attribute in your database. Normally you
> should put a foreign key in the relationnal table Person (which contains an
>addressID). But you can also put a foreign key > in the table Address (which contains
>an personID)
Those solutions are not really the same .. if you put the (fk)personid into the
address table, it means that each address can only belong to one person and that each
person can have multiple addresses.
The otherway around means that an address may be associated with multiple people put
that one person can only have one.
Its a matter of design really. Usually you'd go with the personid in the address table
since thats mostly the case in real life (where people have multiple addresses but
*usually* an address has no more than one inhabitant), strictly speaking that'd be
wrong though, the db-design-proper way to do this would be to create an association
table to map people to addresses with maybe different phone numbers attached to
address+person (like phone at home, phone at work, cell etc).
For more information on database design, google up 'normalisation +db' or 'database
+modelling', that should get you started ...
You need to map every primary key attribute in the database, I'd say (I am not so sure
about that, though) ...
And yes, with OJB you should be able to implement every *proper* database design where
tables are normalized and the model is tailored to 'the real world'.
Greetings,
Wulf
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
