Question

I’m at the stage in a project where I need to extend the user membership fields in a asp.net mvc website.

I have gone through these different thought processes.

1. Using “username” to join users to records. Very bad idea due to a user wanting to change their username etc.

2. Then I thought I could connect the guid of userId to the other tables.

3. Then I thought that using guid might be bad if I needed to use the id as a simple in the future. So I was setting up a link table to joing guid to ints.

4. Decided that i didn’t need that so went back to using guid to link things together, which makes requests more simple.

5. Read loads of discussions of performance being hideous when using guid as clustered index.

I’m now confused, does this mean that the default asp.net authentication is awful for performance?

I know one shouldn’t think about performance too soon, but I do hope to end up with this app being very popular, so if I have to “roll my own” authentication provider, I guess maybe I should do it now.

Any links in the direction of actually doing this would be greatly appreciated as I have been abstracted from this due to asp.net membership stuff doing everything for me.

Thanks everyone.

Answer 1

Guids are a worse choice than ints or bigints, this was discussed and documented inany places. Are they horrible? Not really. There are horror stories of apps using guids for every key and foreign key and what have you, but they are the exception.

The uniqueness of guids has it’s advantages and when used judiciously they can get the job done without issues. I’d much rather use the default provider implementation using guids than roll your own. The skillset to roll your own correct and better than the default one is significant. I don’t say this in a derogatory way, but if you need guidance on understanding the guid impact on erformance then you’re probably not ready to roll your own.

Use the default one, test it, measure and then decide, my 2c.