Is using the built in asp.net authentication provider a bad idea due to guid being used as primary key etc

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

Just implement your own Membership provider and use an int identity(1,1) Primary Key if you're concerned about the performance of the default aspnet Membership provider's use of a GUID PK.

Writing your own Membership Provider is really straightforward and to be honest, if the GUID PK is the only thing that concerns you about the default implementation, then download the source for the built-in provider and change the code to use integers instead of GUIDs. This shouldn't take more than an hour max to do. To complete the picture, run aspnet_sql.exe on your database to get the Membership database and then alter the tables and sprocs to match the changes you make to the source.

Here's the MSDN documentation on implementing a Membership Provider

Answer 2

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.