ER Diagram - Which is the better design?

See Diagram Attached,

which is the better design and why?
ER Diagram 1 or 2 or 3

Entity-Relationship-Diagram123.jpg
KhouAsked:
Who is Participating?
 
Daniel WilsonConnect With a Mentor Commented:
I would say that #2 is superior to #1 b/c #1 needlessly includes AccountID in a couple of tables.

It appears that #3 eliminates the Profile table.  I don't know ... Does what you're modeling really have a "profile" entity?
0
 
HoggZillaCommented:
Please explain, what are you trying to accomplish? The best model for ____?
0
 
KhouAuthor Commented:
@DanielWilson

Thanks

In regards to your comment, If you choose #2, then you would have to find the "AccountID" then match it with the "ProfileID" - thats ok But would it not be better to just use AccountID for everything per user, instead of having an additional ProfileID? (See Diagram attached)

Reason why there is a profile table in the first place: is.............The Profile table keeps all the user's information. There might be another table called "Transaction" under this would be all transactions performed by the user.

But Is there a real need for "Profile" table to have its own "Primary" Key? I would say no, just use AccountID, There would only be a need for ProfileID if the user is to have multiple profiles, if this is not the case, there should be no need to make profileid a primary key, is this correct? or there's an advantage of having a seperate primarykey for each table such as the Profile Table.
0
Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
KhouAuthor Commented:
Attached, ProfileID removed, replaced with AccountID,

is this better than #2? for the situtation above.

erdmod.gif
0
 
KhouAuthor Commented:
REF: Comment - 11.19.2008 at 11:49AM EST, ID: 22990580
   

There seems to be a few words cut off


Correction: Is there a real need for the "Profile" table to have its own "Primary" Key?
I would say no, just use a single AccountID per user. There would only be a need for ProfileID if the user is to have multiple profiles, if this is not the case, there should be no need to make profileid a primary key, is this correct? or there's an advantage of having a seperate primarykey for each table such as the Profile Table.


0
 
KhouAuthor Commented:
Good answer! You got it! 100 points. Thanks
0
 
Daniel WilsonCommented:
Is teh Profile - Account relationship 1-1? If so, merge the tables into 1.  If not, each table needs its own PK.
0
 
KhouAuthor Commented:
Unable to merge profile with account, its rather too complicated right now.

Profile has its own key.
Account has its own key.

In the system Tables that do not have its own key are the joining tables for "many to many" relationships. Other than that every table has its own key.


Went with option #2.

0
 
KhouAuthor Commented:
Not that it can not be merged, its better if it was not merged.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.