将用户配置文件数据存储在用户表还是单独的配置文件表中？

如何解决将用户配置文件数据存储在用户表还是单独的配置文件表中？

| 我正在开发一个需要用户表的快速项目，我希望他们能够存储配置文件数据。当我意识到用户将永远只能拥有一个配置文件时，我已经开始接触ASP.NET配置文件提供程序。 我意识到频繁更改的数据会影响诸如索引和填充之类的内容的性能，但是太频繁了又太频繁了呢？ 如果我每个月每个用户要更改1000个用户的个人资料，那么很多吗？ 还是我们说的更像是用户每小时更改一次个人资料数据？ 我意识到这不是一门精确的科学，但我正在尝试确定阈值在什么时候开始达到峰值，并且由于我的用户个人资料数据可能很少改变，如果我需要打扰额外的工作或仅等待几十年因为这是一个问题。     

解决方法

要考虑的一件事是在表中添加大文本列将如何影响行的布局。一些数据库将大列与其他固定大小的列内联；这将使行的大小可变，这意味着当数据库需要从磁盘中拉出一行时，数据库需要做更多的工作。其他数据库（例如PostgreSQL）将大文本列存储在固定大小的列之外。这会导致在表扫描等期间快速访问固定大小的行，但是需要额外的工作才能拉出文本列。 在数据库方面，1000个用户不是很多，因此不必担心一种方法或另一种方法。 OTOH，很少的一次性项目有一个讨厌的习惯，就是当您不打算将其变成真正的任务关键型项目时，从一开始就正确地这样做是一个好主意。 我认为Justin Cave已经很好地涵盖了索引问题。 只要您正确地构造数据访问权限（即，对用户表的所有访问都通过一堆独立的代码进行），那么为用户更改数据架构无论如何都不会做很多工作。     ,概要文件信息实际上是否需要索引？还是只是根据表的

USER_ID

或其他索引的

USER

列来检索它？如果未对概要文件数据进行索引（这对我来说很可能如此），则对表上的其他索引没有性能影响。 我能想到的关于将配置文件信息放入表中的唯一原因是，与定义用户所需的信息相比，是否有大量数据，以及出于某种原因是否需要完全扫描“ 1”表。在这种情况下，增加表的大小会对表扫描的性能产生不利影响。假设您没有用例，通常需要对

USERS

表进行全面扫描，并且假设该表只有1000行，那可能就不大了处理。