Relations

Posts   
 
    
Nachiket
User
Posts: 3
Joined: 25-May-2007
# Posted on: 25-May-2007 22:18:21   

I am currently evaluating LLBLGen Pro. I have chosen to go with the Adapter approach since, I will be generating code to use in my Webservice. Here is one thing I cannot get to work. I have a database that does not have any relations defined between tables. I created relations manually in the LLBLGen Pro Gui. Here is a small part of my schema.

Customer CustAddress cAddress

CustKey (PK) CustKey(FK) AddressKey(FK) CustName AddressKey(FK) AddressLine1 AddressLine2 Etc.

Customer <1:n> CustAddress <1:1> cAddress.

So, Each customer can have many CustAddress and each CustAddress has only 2 cAddress.

Now the problem is that the generated code shows the correct relation between Customer and CustAddress but there is no relation between CustAddress and cAddress.

Is this something that is not currently supported? Thank you so much for the help.

Nachiket
User
Posts: 3
Joined: 25-May-2007
# Posted on: 25-May-2007 22:29:18   

Ok I did some searching around in this forum. From what I gathered, it is not possible to create 1:1 relation. Am I correct on this? I found out that LLBLGen looks at Unique constraints on tables to determine if it is a 1:n or 1:1 relation. Is there any way to select a relation to be 1:n instead of 1:1. If LLBL can ignore the unique constraint on one of the tables this is possible. But I may be wrong.

Thanks.

arschr
User
Posts: 894
Joined: 14-Dec-2003
# Posted on: 25-May-2007 22:29:55   

AddressKey(FK)

Seems to me that AddressKey should be a primary key in cAddress

Nachiket
User
Posts: 3
Joined: 25-May-2007
# Posted on: 25-May-2007 22:38:13   

Oh I am sorry Typo on my part. You are right arschr. AddressKey is PK in cAddress.

Walaa avatar
Walaa
Support Team
Posts: 14983
Joined: 21-Aug-2005
# Posted on: 28-May-2007 09:49:09   

CustAddress <1:1> cAddress.

First to implement the 1:1 relation between CustAddress and cAddress , I think the following should be your goal:

Customer CustAddress cAddress

CustKey (PK) AddressKey(PK, FK) AddressKey(PK) CustName CustKey(FK) AddressLine1 AddressLine2 Etc.

Which takes us into another question if the relation betwenn the Customer and CAddress is not an m:n relation then why using an intermediate table?

IMHO, it would be better to use the following design:

Customer cAddress

CustKey (PK) AddressKey(PK) CustName CustKey(FK) AddressLine1 AddressLine2 Etc.