0

I am creating a website with the following tables:

  • Members (GUID, UserName, NickName, etc)
  • MemberContacts (emailaddresses, phone#s, etc),
  • MemberSecurityQuestions (for ID challenge questions),
  • MemberBankAccounts (BankID, account#, etc)

I'm uncertain whether to base FK relationships on the GUID or Username (or a combination). Note the GUID is a NewSequentialID().

I'm a noob but theoretically basing all FK on the GUID would be better for index/performance plus if the GUID is never sent to the client more secure -- but might mixing the relationships (i.e. not all on GUID) provide any benefits?

zedfoxus
  • 35,121
  • 5
  • 64
  • 63
Mike S
  • 157
  • 3
  • 13
  • 3
    Welcome to the traditional, never ending debate about 'surrogate versus natural' key. You could find some extra food for thoughts here: http://stackoverflow.com/questions/230351/what-should-i-consider-when-selecting-a-data-type-for-my-primary-key/232985#232985 – Philippe Grondier Sep 16 '15 at 21:46
  • I read that link, thanks. But thinking down the road, IF the GUID is not sent to the client then any returns from the client will be ID'ed by Username Then IF the FKs are based on GUID I'd have to essentially SELECT GUID where UserName=X then make the db do another SELECT from tableB where GUID=result. Alternatively I can send/return the GUID to the client (part of the reason to make it a GUID is so it is useless to a hacker) and then all FKs based on the GUID is a more simple select no? – Mike S Sep 16 '15 at 22:25
  • But then again, why send the GUID to the client? Their UserName has to be sent/available (i.e. the client browser must know who the member is after they have signed in) so the GUID is just extra data. In which case FKs based on the UserName make things simpler??? – Mike S Sep 16 '15 at 22:33

0 Answers0