将用户配置文件数据存储在用户表或单独的配置文件表中？
我正在开发一个需要用户表的快速副项目，我希望它们能够存储配置文件数据。当我意识到用户永远只有一个配置文件时，我已经开始寻求 ASP.NET 配置文件提供程序。
我意识到频繁更改数据会影响索引等内容的性能，但是多久才算太频繁呢？
如果我每个用户每月更改一次个人资料（例如 1000 个用户），这会很多吗？
或者我们更像是用户每小时更改个人资料数据？
我意识到这不是一门精确的科学，但我试图衡量阈值在什么时候开始达到峰值，并且因为如果我应该费心额外的工作或者只是等待几十年，我的用户个人资料数据可能很少会改变成为一个问题。
I'm developing a quick side project that needs a users table, and I want them to be able to store profile data. I was already reaching for the ASP.NET profile provider when I realized that users will only ever have one profile.
I realize that frequently changing data will impact performance on things like indexes and stuff but how frequent is too frequent?
If I have one profile change per month per user happening for say 1000 users, is that a lot?
Or are we talking more like users changing profile data on an hourly basis?
I realize this isn't an exact science but I'm trying to gauge at what point the threshold starts to peak, and since my users profile data will probably rarely change if I should bother the extra work or just wait a few decades for it to be a problem.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
需要考虑的一件事是向表中添加大文本列将如何影响行的布局。有些数据库会存储与其他固定大小的列内联的大列；这将使行的大小可变，这意味着当数据库需要从磁盘上拉出一行时，数据库需要做更多的工作。其他数据库（例如 PostgreSQL）将大型文本列存储在远离固定大小列的地方；这导致在表扫描等过程中可以快速访问固定大小的行，但需要额外的工作来提取文本列。
1000 个用户对于数据库而言并不算多，因此无论哪种方式都无需担心。 OTOH，小型一次性项目有一个令人讨厌的习惯，当您不注意时，它们会变成真正的关键任务项目，因此从一开始就这样做是一个好主意。
我认为贾斯汀·凯夫（Justin Cave）已经很好地讨论了索引问题。
只要您正确地构建数据访问（即对用户表的所有访问都通过一堆独立的代码），那么更改用户的数据模式无论如何都不会做太多工作。
One thing to consider is how adding a large text column to a table will affect the layout of the rows. Some databases will store the large columns inlined with the other fixed size columns; this will make the rows variable sized and that means more work for the database when it needs to pull a row off the disk. Other databases (such as PostgreSQL) store large text columns away from the fixed size columns; this leads to fixed sized rows with quick access during table scans and the like but an extra bit of work is needed to pull out the text columns.
1000 users isn't that much in database terms so there's probably nothing to worry about one way or the other. OTOH, little one-off side projects have a nasty habit of turning into real mission critical projects when you're not looking so doing it right from the beginning is a good idea.
I think Justin Cave has covered the index issue well enough.
As long as you structure your data access properly (i.e. all access to your user table goes through one isolated pile of code) then changing your data schema for users won't be much work anyway.
个人资料信息实际上需要索引吗？或者您只是要根据表的
USER_ID或其他一些索引USER列来检索它？如果配置文件数据未建立索引（这在我看来很可能），那么对表中的其他索引不会产生性能影响。我能想到的关心将个人资料信息放入表中的唯一原因是，与定义用户的必要信息相比，是否有大量数据，以及
USER表是否需要填满由于某种原因扫描。在这种情况下，增加表的大小会对表扫描的性能产生不利影响。假设您没有定期对USERS表进行完整扫描的用例，并且考虑到该表只有 1000 行，这可能不是一个大问题交易。Does the profile information actually need to be indexed? Or are you just going to be retrieving it based on the
USER_IDof the table or some other indexedUSERcolumn? If the profile data isn't indexed, which seems likely to me, than there are no performance impacts to other indexes on the table.The only reason I can think of to be concerned about putting profile information in the table is if there is a lot of data compared to the necessary information to define a user and if the
USERtable needs to be full scanned for some reason. In that case, increasing the size of the table would adversely affect the performance of a table scan. Assuming that you don't have a use case where it's regularly going to make sense to do a full scan on theUSERStable, and given that the table will only have 1000 rows, that's probably not a big deal.