使用ASP.NET档案配置文件吗？

Question

我需要存储已认证用户的一些属性（我正在使用Membership API），并且我需要在使用Profiles或添加一个新表与UserId作为主键之间做出选择。似乎使用Profiles快速且需要更少的工作量，但是我看到以下缺点：

1. 属性值被压缩到单个ntext列中。将来我可能会有更新用户属性的SQL脚本。查询ntext列并尝试更新值听起来有点错误。
2. 如果我选择添加新的用户特定属性，并想为所有现有用户分配默认值，是否可能？

我的第一印象是，在长期运行中使用Profiles可能会导致维护方面的问题。你有什么想法吗？

- DotnetDude

---

+1 - 更好的问题。这表明你已经自己检查了问题，但仍然有疑问，显示出你的主动性。 - Sky Sanders

我已经想出了一种适合我的查询默认配置文件提供程序数据的方法：https://dev59.com/eVfUa4cB1Zd3GeqPJp6s#13747590 - Ronnie Overby

Answer 1

有一篇MSDN文章（现在在ASP.NET上）讨论了如何创建一个档案表提供程序，链接为http://www.asp.net/downloads/sandbox/table-profile-provider-samples。其思想是将档案数据存储在表中而不是行中，使仅使用SQL查询更加容易。

此外，SQL Server 2005/2008支持通过服务和CLR代码获取数据。您可以通过API访问Profile数据而不是直接访问底层表。

至于第二点，您可以为属性设置默认值，虽然这不会立即更新其他档案，但下次访问该档案时将更新档案。

- Jonathan Bates

---

您能否就“Profile Table Provider”在大型用户群体中的灵活性和性能发表评论？ - DotnetDude

如果您的个人资料数据和/或访问要求不太复杂，那么使用+1是正确的选择。由于默认动态配置文件实现所需的序列化/反序列化，基于表格的提供程序的性能要好得多。 - Sky Sanders

@DotNetDude：恐怕这要取决于您对“大型”的定义。至于灵活性，通过使用提供程序，开发人员可以继续在代码中使用Profile API。这使得以一般的方式开发解决方案更容易被搜索引擎（或如果您愿意的话，是StackOverflow）所收录，而不是使用一些自定义的特定方案。性能指标还必须考虑到问题点＃1的原始意图：将配置文件数据以比标准Profile数据库模式更容易查询的格式可用。表提供程序在这方面获得了一些优势。 - Jonathan Bates

Answer 2

在我看来，你已经回答了自己的问题。如果你的第一点可能发生，那么SQL表是唯一明智的选择。

- Tor Haugen

Answer 3

看看这个问题...

ASP.NET内置用户配置文件与旧式用户类/表

内置配置文件设计不良的第一个提示是它们在关系数据库中使用分隔数据。在关系型数据库管理系统中，有一些情况下使用分隔数据是有意义的，但这绝对不是其中之一。

除非你有特定的原因要使用ASP.Net配置文件，否则我建议你使用单独的表。

- kervin

---

设计不好？那你如何设计一个动态个人资料系统，只需修改配置文件即可立即使用...在2003年？我想说的是，当时有一些非常聪明的人把它放在了那里，而你的“提示”则是错误的。 - Sky Sanders

@code poet：踩票并不是用来表示不同意观点的 :) 我认为将分隔数据放在单个列中作为通用配置文件数据的设计是不好的。已经有众所周知的表格设计来解决这个问题。 - kervin

如果您看到错误信息，请投票否决它。http://stackoverflow.com/faq - 平面地将ASP.Net配置文件描述为设计不良是错误的信息，可能会使一些经验较少的人不必要地转向使用默认提供程序提供的非常简单的设施，而不是使用不必要复杂的售后专业解决方案。再次问一下，如果只使用配置，您将如何提供相同的功能，即提供瞬态、动态用户元数据的OOB能力？ - Sky Sanders

我必须说，你的结论也是错误的建议。除非你有特定的理由不使用默认提供者，否则最好不要重复造轮子。 - Sky Sanders