是否使用 ASP.NET Profile？
我需要存储经过身份验证的用户的一些属性（我正在使用 Membership API），并且需要在使用配置文件或添加以 UserId 作为 PK 的新表之间做出选择。看来使用配置文件速度很快，并且需要的前期工作较少。但是，我看到了以下缺点：
- 配置文件值被压缩到单个 ntext 列中。在将来的某个时候，我将拥有可以更新用户属性的 SQL 脚本。查询 ntext 列并尝试更新值对我来说听起来有点问题。
- 如果我选择添加新的用户特定属性并希望为所有现有用户分配默认值，这可能吗？
我的第一印象是，从长远来看，使用配置文件可能会导致维护问题。想法？
I need to store a few attributes of an authenticated user (I am using Membership API) and I need to make a choice between using Profiles or adding a new table with UserId as the PK. It appears that using Profiles is quick and needs less work upfront. However, I see the following downsides:
- The profile values are squished into a single ntext column. At some point in the future, I will have SQL scripts that may update user's attributes. Querying a ntext column and trying to update a value sounds a little buggy to me.
- If I choose to add a new user specific property and would like to assign a default for all the existing users, would it be possible?
My first impression has been that using profiles may cause maintainance headaches in the long run. Thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
看看这个问题...
ASP .NET 内置用户配置文件与旧的 stile 用户类/表
内置配置文件设计不当的第一个提示是它们在关系数据库中使用分隔数据。在某些情况下，RDBMS 中的数据分隔是有意义的，但这绝对不是其中之一。
除非您有特定原因使用 ASP.Net 配置文件，否则我建议您使用单独的表。
Check out this question...
ASP.NET built in user profile vs. old stile user class/tables
The first hint that the built-in profiles are badly designed is their use of delimited data in a relational database. There are a few cases that delimited data in a RDBMS makes sense, but this is definitely not one of them.
Unless you have a specific reason to use ASP.Net Profiles, I'd suggest you go with the separate tables instead.
MSDN 上有一篇文章（现在在 ASP.NET http:// www.asp.net/downloads/sandbox/table-profile-provider-samples），讨论如何制作配置文件表提供程序。这个想法是将 Profile 数据存储在表中而不是行中，从而更容易仅使用 SQL 进行查询。
更重要的是，SQL Server 2005/2008 提供了通过服务和 CLR 代码获取数据的支持。您可以想象通过 API 而不是直接访问底层表来访问配置文件数据。
对于第 2 点，您可以将属性设置为默认值，虽然这不会立即更新其他配置文件，但在下次访问该配置文件时将会更新该配置文件。
There was an article on MSDN (now on ASP.NET http://www.asp.net/downloads/sandbox/table-profile-provider-samples) that discusses how to make a Profile Table Provider. The idea is to store the Profile data in a table versus a row, making it easier to query with just SQL.
More onto that point, SQL Server 2005/2008 provides support for getting data via services and CLR code. You could conceivably access the Profile data via the API instead of the underlying tables directly.
As to point #2, you can set defaults to properties, and while this will not update other profiles immediately, the profile would be updated when next it is accessed.
在我看来，你已经回答了你自己的问题。如果您的第 1 点很可能发生，那么 SQL 表是唯一明智的选择。
Seems to me you have answered your own question. If your point 1 is likely to happen, then a SQL table is the only sensible option.