我正在开发一个需要用户表的快速项目，我希望他们能够存储配置文件数据。当我意识到用户只有一个配置文件时，我已经到达了ASP.NET配置文件提供程序。
我意识到频繁更改的数据会影响索引和内容之类的性能，但是频繁发生的频率是多少？
如果每个用户每个月发生一次配置文件更改，例如1000个用户，那是不是很多？
或者我们是否更像是每小时更改个人资料数据的用户？
我意识到这不是一门精确的科学，但我试图衡量门槛在什么时候开始达到峰值，因为我的用户档案数据可能很少会改变，如果我应该打扰额外的工作或只是等待一些几十年来它成为一个问题。
答案 0 :(得分：5)
要考虑的一件事是如何向表中添加大型文本列将影响行的布局。一些数据库将存储与其他固定大小列内联的大列;这将使行变量大小，这意味着当数据库需要从磁盘中拉出一行时，它可以为数据库做更多的工作。其他数据库（如PostgreSQL）存储远离固定大小列的大文本列;这会导致固定大小的行在表扫描等过程中快速访问，但需要额外的工作来拉出文本列。
1000个用户在数据库方面并不是那么多，所以可能没有什么可担心的。 OTOH，小小的一次性项目有一个讨厌的习惯，当你不看的时候变成真正的任务关键项目从一开始就这样做是个好主意。
我认为Justin Cave已经足够了解索引问题。
只要您正确构建数据访问（即对用户表的所有访问都通过一堆独立的代码），那么为用户更改数据模式无论如何都不会有太多工作。
答案 1 :(得分：4)
是否真的需要将个人资料信息编入索引？或者您只是根据表的USER_ID或其他一些索引USER列来检索它？如果配置文件数据没有被索引，这对我来说似乎比对表中的其他索引没有性能影响。
我能想到关注在表中放置配置文件信息的唯一原因是，如果有大量数据与定义用户的必要信息进行比较，以及USER表是否需要填满扫描出于某种原因。在这种情况下，增加表的大小会对表扫描的性能产生不利影响。假设你没有一个用例，它经常在USERS表上进行全面扫描是有意义的，并且假设该表只有1000行，那可能不是什么大问题。 / p>