Modifying ASP.NET Membership Schema

Question

So I'm using Forms Authentication on my site, and I've set up all the tables and stored procedures in SQL Server. The only thing is, I really don't think I need all these tables, and I'm not a big fan of the table names either.

For instance, I'm using the authentication for employees, so it would be nice to change the table name from "aspnet_Users" to "Employees". And I don't really need the Personalization tables. But I don't know if that would break anything.

Is it possible to modify/delete tables and stored procedures without messing everything up?

possible duplicate of [Custom forms authentication in MVC](http://stackoverflow.com/questions/4586891/custom-forms-authentication-in-mvc) — Dave Swersky, Jan 03 '11 at 20:11

score 9 · Accepted Answer · answered Jan 03 '11 at 20:17

Steven, I take it you ran the aspnet_regsql.exe command line tool to add these database objects? Alternatively, you can add just the necessary tables/views/stored procedures for different parts of Membership by running the applicable SQL scripts, which you'll find in the %WINDIR%\Microsoft.Net\Framework\version folder (where version is the .NET version you are using, like v4.0.30319).

There you'll find files named InstallCommon.sql, InstallMembership.sql, InstallRoles.sql, InstallProfile.sql, InstallSqlState.sql, and so on. You'll need to run InstallCommon.sql and then just those other files you need. So if you need just Membership and Roles, you'd run InstallCommon.sql, InstallMembership.sql, and InstallRoles.sql. In this way your database would not include the tables/views/sprocs for profile, SQL state, and so on.

All that being said, I'd just leave in all of the database objects that ASP.NET added. It's probably more work than it's worth to add just the subset of interest and, who knows, you may need to implement profile or Health Monitoring later so why not have these other database objects in place and ready to go.

And to answer your first question - No, there is no way to change the table name from aspnet_Users to Employees. However, it's not uncommon to create your own table (perhaps called Employees) that stores information about an employee. This table, then, would have a foreign key back to aspnet_Users that links an employee to a particular login account. See Storing Additional User Information for a look at how this can be accomplished.

Happy Programming!

Thanks Scott, that link is exactly what I needed. – Steven Jan 04 '11 at 04:14 — Steven, Jan 04 '11 at 04:14

score 2 · Answer 2 · answered Jan 03 '11 at 20:16

2

Why not write a simple SqlMembershipProvider?

Edit: No, the default providers expect that schema. I would not recommend modifying it.

answered Jan 03 '11 at 20:16

Bobby D

2,129
14
21

If it's not a question, but an answer it's right. This is the only possible method, but it's quite a big task. – buc Jan 03 '11 at 20:19
No, it's an answer.. writing Providers isn't that difficult at all once you find one or two samples (and there are plenty of them out there) to help you along.. – Bobby D Jan 04 '11 at 04:35

score 1 · Answer 3 · answered Jan 03 '11 at 21:11

1

Have you considered just leaving the authentication stuff in it's own database?

answered Jan 03 '11 at 21:11

Wyatt Barnett

15,573
3
34
53

score 1 · Answer 4 · answered Jan 03 '11 at 21:31

You can change all references to aspnet_Users to Employees in the .sql scripts mentioned by Scott Mitchell but it isn't recommended. The Membership / Roles API uses stored procs. So if you don't change storedProc names you will be fine.

The issues might be if any future changes to membership / Roles providers and/or API.

Also say in future you need to give access to some users who are not the Employees, the renaming will lose its meaning.

Modifying ASP.NET Membership Schema

4 Answers4