Hi Sylvain, > 1) [OJB question] do you need to create an osFK attribute in Workstation class?
I not really sure about this, the examples that I've seen and from what I gather from the tutorials, it seems to be mandatory to map each column in the database to a field in your class .. this excerpt from the tutorial3 affirms this believe: "Just write a complete ClassDescriptor for each class that contains FieldDescriptors for all (also inherited) attributes. " But this was also under heading 'inheritance mapping' so I don't know if it's really relevant. Anyways, you can try it out easily, once you got your first app working with ojb .. just delete the attribute from the repository_user.xml and see what happens. > 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? I wouldn't know why not, in generell ... your java code does only fit but one solution though: workstation N : 1 os where the osFK is in the worksation table. Greetings, Wulf -----Urspr�ngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 12. Dezember 2002 17:27 An: [EMAIL PROTECTED] Betreff: RE: Newbie question: associations 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]>
<<application/ms-tnef>>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
