2

我知道网站上已经有一些关于这个主题的问题......

我只是想了解在流量巨大的网站上使用ASP.NET 配置文件提供程序是否安全？

在我看来，它的布局效率低下。您存储属性名称（它是一个字符串）和属性值（它也是一个字符串）。如果您只是想在配置文件中存储甚至年龄，那么您将不必要地将字符串“年龄”一遍又一遍地存储在数据库中，而对于自创表，您可以只添加一个标题为年龄的列，而没有冗余？

（我只是想确保我没有遗漏任何东西，因为我对它相当陌生。）

4

3 回答 3

8

配置文件提供者故意使用 EAV（实体属性值）设计，因为配置文件通常具有稀疏填充的模式 - 也就是说，有许多潜在属性，但只有少数属性会用于给定的单个实体，从一个实体到另一个实体，使用的少数几个差异很大。

让我们举一个完全任意的例子——假设只有十分之一的用户想要提供他们的年龄。现在让它成为一个专栏似乎更像是一种浪费，不是吗？

但是，如果您的应用程序强制要求年龄怎么办？好的，该列会为每个人填充。但是，如果您需要在配置文件中记下“用户不想再看到这个晦涩的对话框”，该怎么办。您是否真的希望应用程序中的每个对话框都有一个列，无论用户是否想看到它？可能不是。当您深入了解任何重要范围的应用程序的一次性细节时，EAV 实际上成为更经济的选择。

一般来说，它的扩展性很好（比你想象的要好得多）。具体来说，没关系 - 一如既往，使用有效的方法并在出现性能问题时修复它们。无论配置文件提供程序的可扩展性限制是什么，当您遇到它们时，您就会知道。我保证两件事——（1）在你必须解决之前，你必须解决很多其他你没有预料到的性能问题；(2) 如果您的网站获得了足够的流量来破坏配置文件提供者，那么这是一个很好的问题。

于 2009-09-02T05:47:32.067 回答
0

我同意 Rex M 的观点，除非您需要按年龄对所有用户进行排序或使用汇总的个人资料数据执行其他程序。然后你可以考虑自己滚动。但是对于仅存储您在逐个用户的基础上在这里和那里访问的属性，Rex M 是正确的。

于 2009-09-02T05:59:01.823 回答
0

我知道你的意思。用另一个包含必填字段列的表来补充配置文件提供者的表不是有意义吗？或者你认为加入的开销不会让它不值得吗？

于 2009-09-02T22:21:46.457 回答