Re: One to One Relationship

"Wayne Hinch" <hinchy2000_at_lineone.net> wrote:
> But if you merge the tables you are not meeting the ERD standards which
> is lots of small tables containing different pieces of information.
>
> I.e. Would you have a Customer table and then a Payment Method table or
> merge them together. I was thinking from the point of view whereby is it
> easy to make an enhancement to two tables (Customer and Payment Method)
> when such functionality is needed to hold two 'Payment Methods' for one
> customer (Two different credit cards).

If the app isn't prepared to deal with two payment methods then retrofitting it to do so wouldn't be very easy.

It seems like you know from the start it shouldn't be 1-to-1 relationship, but rather a 1-to-many relationship. But for some reason you want to initially do it wrong, with 1-to-1, in such a way that it will later be easy to fix it. Why not just do it right in the first place?

But if for some strage reason this is what you want, then the way to do it seems fairly simple. You make everything just as if it were a 1-to-many, but you then put a unique constraint on the foreign key column of the psuedo-many table. (or course, this allows there to be no payment method, so really it would be (0 or 1) to 1 relationship.)

Xho

-- 
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service              New Rate! $9.95/Month 50GB