Professional ASP.NET 3.5 Security, Membership, and Role Management with C# and VB

12.1. Understanding the Common Database Schema

All the default SQL-based providers in ASP.NET 2.0 and ASP.NET 3.5 share a common schema. The common tables and supporting stored procedures allow ASP.NET to share the same user data across the Membership, Role Manager, Profile, and Web Parts Personalization features. If you choose to use multiple features, and you take the extra step of pointing the various features at the same database, the end result is that all ASP.NET features will share a common set of user and application data. With this scenario, you can work with data through a feature's object API or directly against the database. At both levels of programming, you will be dealing with the same piece of user data.

This integration is not actually required to use any of the features. The integration support is nice to have if you choose to install all the feature schemas in a single database. However, it's possible to install each feature's database schema into a separate database, potentially on completely different servers. If you do this, all the features will still work. Because each one depends on a username and the application name from configuration as the identifying data for a user, each feature's database will have its own unique row of data identifying a user. For example, if you install three ASP.NET features into three different databases, over time the user "foo" will end up with three records: one in each feature database.

This approach leads to object level ...