修改 ASP.NET 成员资格架构
因此，我在站点上使用表单身份验证，并在 SQL Server 中设置了所有表和存储过程。唯一的问题是，我真的认为我不需要所有这些表，而且我也不喜欢这些表名。
例如，我正在对员工使用身份验证，因此最好将表名称从“aspnet_Users”更改为“Employees”。而且我真的不需要个性化表。但我不知道这是否会破坏任何东西。
是否可以修改/删除表和存储过程而不搞乱一切？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Steven，我想您运行了
aspnet_regsql.exe命令行工具来添加这些数据库对象？或者，您可以通过运行适用的 SQL 脚本为成员资格的不同部分添加必要的表/视图/存储过程，您可以在%WINDIR%\Microsoft.Net\Framework\version文件夹（其中版本是您正在使用的.NET版本，例如v4.0.30319）。在那里您将找到名为
InstallCommon.sql、InstallMembership.sql、InstallRoles.sql、InstallProfile.sql的文件、InstallSqlState.sql等等。您需要运行InstallCommon.sql，然后运行您需要的其他文件。因此，如果您只需要成员身份和角色，则可以运行InstallCommon.sql、InstallMembership.sql和InstallRoles.sql。这样，您的数据库将不包含配置文件、SQL 状态等的表/视图/存储过程。话虽如此，我只是保留 ASP.NET 添加的所有数据库对象。仅仅添加感兴趣的子集可能比添加感兴趣的子集更多的工作量，谁知道，您可能需要稍后实现配置文件或运行状况监控，所以为什么不将这些其他数据库对象放在适当的位置并
准备出发了。
回答您的第一个问题 - 不，无法将表名称从
aspnet_Users更改为Employees。但是，创建自己的表（可能称为Employees）来存储有关员工的信息并不罕见。然后，该表将有一个返回到aspnet_Users的外键，将员工链接到特定的登录帐户。请参阅存储其他用户信息了解如何执行此操作可以实现。快乐编程！
Steven, I take it you ran the
aspnet_regsql.execommand 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\versionfolder (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 runInstallCommon.sqland then just those other files you need. So if you need just Membership and Roles, you'd runInstallCommon.sql,InstallMembership.sql, andInstallRoles.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_UserstoEmployees. However, it's not uncommon to create your own table (perhaps calledEmployees) that stores information about an employee. This table, then, would have a foreign key back toaspnet_Usersthat links an employee to a particular login account. See Storing Additional User Information for a look at how this can be accomplished.Happy Programming!
为什么不编写一个简单的 SqlMembershipProvider ？
编辑：不，默认提供程序需要该架构。我不建议修改它。
Why not write a simple SqlMembershipProvider?
Edit: No, the default providers expect that schema. I would not recommend modifying it.
您是否考虑过将身份验证内容保留在自己的数据库中？
Have you considered just leaving the authentication stuff in it's own database?
您可以将 Scott Mitchell 提到的 .sql 脚本中对 aspnet_Users 的所有引用更改为Employees，但不建议这样做。成员/角色 API 使用存储过程。因此，如果您不更改storedProc 名称，就没有问题。
问题可能是未来成员资格/角色提供者和/或 API 是否发生任何变化。
另外，将来您需要授予某些非员工用户的访问权限，重命名将失去意义。
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.