如何最好地利用 ASP .NET 会员数据库？
我正处于开发网络应用程序的早期开发阶段。我目前正在考虑是否应该使用 ASP .NET 会员资格还是自己编写。我更倾向于使用 ASP .NET 会员资格来节省一些开发时间。需要帮助来澄清有关如何最好地利用会员数据库的一些歧义：
- 会员创建一个新的数据库。哪一个更好，为我使用相同的数据库 应用程序数据库或为我的应用程序创建一个新数据库？为什么？
- 如果我为我的应用程序创建一个新数据库。在我的应用程序数据库中创建新的用户表或在成员资格数据库中重用/扩展用户表，哪一个更好？
预先感谢，
RWendi
I'm in early development stage of developing a web application. Im currently reviewing as to whether I should use ASP .NET Membership or write my own. Im more lenient towards to using ASP .NET Membership to save me some development time. Need help to clear up some ambiguities on how to best utilize membership database:
- Membership creates a new database. Which one is better, to use the same database for my
application database OR creating a new database for my application? Why? - If I go for creating a new database for my application. Which one is better, creating a new user table in my application database or reusing/extending the user table in the membership database?
Thanks in advance,
RWendi
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我本人是会员/角色/个人资料提供商的粉丝，所以我有点偏见。基本上，如果我要评估项目使用什么，我会查看需求。如果默认功能适合您，我认为没有理由实现您自己的会员功能。它具有许多功能和一些非常好的优化（例如出于性能原因使用小写用户名和电子邮件的列）。
我通常为我的数据和会员资格创建一个数据库。我通过添加用户名列而不是外键来链接其他表，以避免删除用户时出现问题。更重要的是，GUID（即用户 ID）无法通过成员资格提供程序接口检索，如果您想通过用户 ID 引用内容，您将需要编写自己的存储过程。
I myself am a fan of the Membership/Roles/Profile providers so I'm a bit biased. Basically if I were to evaluate what to use for a project I would look at the requirements. I can see no reason to implement your own membership functionality if the default works for you. It has many features and some pretty good optimizations (like columns with lowercase username and email for performance reasons).
I usually create a single database for my data and my membership. I link other tables by adding a username column but not a foreign key to avoid problems with deleting users. What is more the GUID that is the user id cannot be retrieved with the membership provider interface and you will need to write your own stored procedure if you want to reference stuff by user id.
关于是否使用单独的数据库的问题，如果您有资源（例如，您不在具有单个 sql server 数据库的共享主机上），那么单独的数据库往往是最佳选择。主要优点是用户数据往往是特定于应用程序的（例如，您在 QA 中不需要生产用户数据），因此将其单独存在会使事情变得更干净，因为您只需要处理应用程序的数据。
On the question of separate database or not, separate tends to be the way to go if you have the resources (eg--you aren't on a shared host with a single sql server db). The main advantage is that the user data tends to be pretty application specific (eg--you don't need production user data in QA), so having it live separately makes things a bit cleaner as you only need to schlep about the application's data.