我正在開發一個需要用戶表的快速端項目，我希望他們能夠存儲配置文件數據。當我意識到用戶將只有一個配置文件時，我已經到達ASP.NET配置文件提供程序。將用戶配置文件數據存儲在用戶表或單獨的配置文件表中？
我意識到經常變化的數據會影響像索引和東西這樣的性能，但頻繁出現頻率如何？
如果我每個用戶每個月發生一次配置文件更改（例如1000個用戶），這是多少？
或者我們說的更像是用戶每小時更改一次個人資料數據？
我意識到這不是一門精確的科學，但我試圖衡量閾值開始達到頂點的時間點，而且因爲我的用戶配置文件數據可能很少會改變，如果我應該打擾額外的工作或等待幾十年來它是一個問題。
要考慮的一件事是如何向表中添加大型文本列將影響行的佈局。一些數據庫將存儲與其他固定大小的列內聯的大型列;這將使行的大小可變，這意味着當數據庫需要從磁盤上取下一行時需要更多的工作。其他數據庫（如PostgreSQL）將大型文本列遠離固定大小的列存儲;這導致固定大小的行在表掃描等過程中快速訪問，但需要額外的工作來拉出文本列。
1000個用戶在數據庫方面沒有那麼多，所以可能沒有什麼可擔心的。 OTOH，當你不想從一開始就這麼做的時候，一點一次性的項目都會變成真正的關鍵任務項目，這是一個好主意。
我認爲Justin Cave已經足夠好地覆蓋了指數問題。
只要你正確地構造你的數據訪問（即對你的用戶表的所有訪問都要經過一堆單獨的代碼），那麼改變你的用戶數據模式不會有多大的作用。
配置文件信息實際上是否需要編入索引？或者你只是要根據表格的USER_ID或其他索引USER列檢索它？如果配置文件數據沒有編入索引（這在我看來很有可能），而不是對錶中其他索引的性能影響。
我能想到的唯一理由是擔心把配置文件信息的表，如果有比必要的信息來定義一個用戶時，如果USER表需要全掃描一些大量的數據原因。在這種情況下，增加表的大小會對錶掃描的性能產生不利影響。假設你沒有一個用例，它對USERS表進行全面掃描是有意義的，並且該表只有1000行，這可能不是什麼大問題。