Bad idea to alter asp.net mvc framework autogenerated database?

Question

Is it a bad idea (and if why?) to add a a column to the auto generated asp.net (ASPNETDB.MDF, visual studio 2008, mvc framework) "user roles - database"?

(E.g I want to add the columns RealName and LastName to the aspnet_Users table in the database.)

The reason I want to add a column instead of creating an entire new table is to avoid the doule maintenance issue and unnecessary redundancy

Answer 1

Hi,

In my opinion that autogenerated database should be replaced by a normal table in application database or at least there should be an official solution to this problem.

I heard that this is quite good solution: http://www.asp.net/downloads/sandbox/table-profile-provider-samples/

Answer 2

why dont you create a new table with a Foriegn Key restraint? It seems like a bad idea to add a column to the aspnetdb...it will be a nightmare if you ever need to recreate your db...

Answer 3

There are two generation schemes that are used (from Pragmatic Programmer):

• Those that are used once to generate code
• Those that are used all the time to have some code synced

The ones that are used for syncing, the results should not be modified, since they could be overridden at a later date when the generation gets done again.

In the case of your generated asp.net database, there is no reason for you to rerun the generation, so it would be OK to edit it.

The only scenario under which you would rerun the generation of the db is if microsoft releases a new version of the users database and you want to use the new one (in this case you might have to edit some parts of your application, so you could readd those two fields), or if you want to regenerate the database with different options. Both of these happen if you are not happy with your current db.

Answer 4

First, those tables aren't really anything specific to MVC: they're created by/for the default AspNetSqlMembershipProvider. (Also applies to other kinds of ASP.NET applications.)

You could probably add new columns safely, but the membership provider wouldn't "see" them. It does provide its profile mechanism to store extra information (which gets serialized, and stored in the aspnet_Profiles table).

If you need to store lots of additional information about the user, you might also check out this sample membership provider that stores profile information in first-class tables, rather that in profile blobs.