One to One Relationship

From: Norman Dunbar <Norman.Dunbar_at_lfs.co.uk>
Date: Tue, 18 Mar 2003 11:33:07 -0000
Message-ID: <E2F6A70FE45242488C865C3BC1245DA703719B2A@lnewton.leeds.lfs.co.uk>

Hi Wayne,

I'd be of the opinion that a customer -> payment method is *not* 1:1. We just happen to build instalment credit applications here where I work, and there is a 1:MANY relationship simply because, as you mention, there may well be a need for a customer to have two or more credit cards, pay by cash or cheque/check etc.

I think you can ignore the 1:1 and leave it as 1:MANY which is what it really is - unless of course you have a business rule to implement which says that customers can only use a single method to pay their bills :o)

HTH Regards,
Norman - not the world's best database designer !

Norman Dunbar
Database/Unix administrator
Lynx Financial Systems Ltd.
mailto:Norman.Dunbar_at_LFS.co.uk

Tel: 0113 289 6265
Fax: 0113 289 3146
URL: http://www.Lynx-FS.com


-------------------------------------

-----Original Message-----
From: Wayne Hinch [mailto:hinchy2000_at_lineone.net] Posted At: Tuesday, March 18, 2003 10:13 AM Posted To: server
Conversation: One to One Relationship
Subject: Re: One to One Relationship

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). Whereas merging the tables together it would
be alot of work to implement the functionality above. Also what about security?

Wayne Received on Tue Mar 18 2003 - 05:33:07 CST