Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
blicci
Starting Member
1 Post |
 Posted - 2006-03-09 : 22:14:20
|
| I'm just trying to get some opinions on something.I have a base table [ACCOUNT]. To simplify the question I'll say the table only has three columns [ACCOUNTID],[FIRMID] and [SPONSORID].[ACCOUNTID] is the PK[FIRMID] is a FK pointing to a table called [FIRM][SPONSORID] is a FK pointing to a table called [SPONSOR]In the [SPONSOR] table there are names like ABC.Sponsor has a relationship with firm in that Sponsors can have many firms but the firm could also be the sponsor. And there is another table that links these two together that is used simply to limit the choices a user has in the front end after they choose a sponsor.Ex. Sponsor ABC can have a firm of ABC, DEF, GHIMy thinking is that since they are different entities they should be in seperate tables, even though there may be duplicate entries such as ABC across the two tables. One of my co-workers argues that if the name changes or something to the sponsor you then need to update the firm as well. So if ABC changes to 123 the firm will need to be changed to 123 as well. Therefore FIRMs and SPONSORs should be combined.Your opinions would be appreciated.Thank You |
|
|
Wanderer
Master Smack Fu Yak Hacker
1168 Posts |
Posted - 2006-03-10 : 01:40:56
|
My point of view, given the above, is that you have a single table Firm. You shouldn't use what the comanies role in an account to create a new company. so:[Firm] [Account ]------ ------------|id | |AccountId ||... |-o----------|FirmId ||... |-o----------|SponsorId |----- |... | ------------ the ... indicates other attributes.In this manner, when Firm ABC changes it's name to ABC Inc. you change it once - on the record that represents the Firm.HTH*##* *##* *##* *##* Chaos, Disorder and Panic ... my work is done here! |
 |
|
|
|
|
|
Opinions on DB Schema