Me too.  Not only are the joins expensive, but it's a lot of extra data,
too.  My database is already key-heavy without the extra tables.
 
Jeff

-----Original Message-----
From: Dumitru Sbenghe [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 23, 2001 8:04 AM
To: Orion-Interest
Subject: RE: O/R mapping


I care; If you store a 1-m relation in 3 tables, to get the
corresponding data from the third table 
for a PK from the first table, you must join the second table with the
third table; 
A join is slower than a simple select;
 
If you store a 1-m relation in only two table (the normal way) , you do
that with only a simple select.
 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Magnus Rydin
Sent: mardi 23 janvier 2001 14:51
To: Orion-Interest
Subject: SV: O/R mapping



One of the things I like best with EJB is that I dont have to care about
how my objects are stored (Yes, im a CMP fanatic).

So my personal contribution to the subject must be:   
who cares how many tables are used 'back there' ? :) 

> -----Ursprungligt meddelande----- 
> Från: Daniel Cardin [ mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> ] 
> Skickat: den 23 januari 2001 05:01 
> Till: Orion-Interest 
> Ämne: RE: O/R mapping 
> 
> 
> I'd like to point out that a third table is only needed for a N-M 
> (many-to-many) relationship. 
> In the case of a 1-N relationship, simply have a foreign key to the 
> master table. 
> 
> For example : 
> 
> Customer object refers to a Country object 
> you a Customer will only have one Country object. you do NOT need a 
> third table to map this. 
> Simply add a field in Customer that contains the foreign key to the 
> Country object. 
> 
> The EJB 2.0 mapping is Simple 
> 
> 
> 
> Customer ... 
> 
> public abstract Country getCountry(); 
> public abstract void setCountry(Country aCountry); 
> 
> and in Country 
> 
> public abstract Collection getCustomers(); 
> public abstract void setCustomer(Collection customers); 
> 
> This is fully supported by Orion, which will populate the collection 
> object automatically. 
> 
> Cheers, 
> 
> Daniel 
> 
> 
> -----Message d'origine----- 
> De : Tony J Brooks [ mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ] 
> Envoyé : 22 janvier, 2001 11:27 
> À : Orion-Interest 
> Objet : RE: O/R mapping 
> 
> 
> 
> Hi Theis, 
> 
> As much as I can remember, there *is* - definitely - a need for an 
> intermediate third table to contain the mapping information.  By using

> this 
> third table, you eliminate data replication/redundancy in the 
> other two 
> tables. 
> 
> To my knowledge this is a common technique.  ER tools typically create

> such 
> an intermediate table for you when you select a relationship to be 
> 'zero/one/many to many'.  Whether you see that on your diagram is 
> another 
> matter, but you will definitely see it in your DB ;) 
> 
> Apologies if I have misunderstood your question. 
> 
> Bye for now, 
> Tony. 
> 
> -----Original Message----- 
> From: [EMAIL PROTECTED] 
> [ mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> ]On Behalf Of 
> [EMAIL PROTECTED] 
> Sent: 22 January 2001 15:10 
> To: Orion-Interest 
> Subject: O/R mapping 
> 
> 
> Hi! 
> 
> I have been reading the complex-or example and ploughed 
> through the atm 
> example. In the complex-or example it is stated that collections are 
> mapped 
> to an another table and that the reason for this is normalization. The

> Atm 
> example is also following this principle. 
> 
> Is this really correct? I have never seen the necessity for mapping 
> anone 
> to many relation to a third table (even though it was a long 
> time ago I 
> read the rules of normalization I'm very doubtful that this 
> is correct). 
> Could someone tell me the rational behind this. 
> 
> If this not true, how does the xml look like (in the 
> orion-ejb-jar.xml) 
> when you only map the relation as a foreign key? 
> 
> Regards 
> 
> /Theis 
> 
> 
> 
> 


Reply via email to