我正在使用SQL Server來存儲有關每個用戶的幾位信息。一些項目（例如用戶名/密碼）很少會改變，但其他項目每隔幾秒改變一次（例如經度/緯度）。繼續在SQL Server中更新同一行是否很糟糕？
我希望這個系統在使用時，大部分工作日的，由幾個hundered用戶。因此， 每個用戶每天10,000次更新到此表。
他們是不利的存儲不斷變化的信息和大多數靜態信息在同一行？我應該將靜態信息保存在一張表中，並在另一張表中更改信息？
只要邏輯上屬於一起，您可以將所有信息保留在一張表中。您冒着用這種方式鎖定用戶行的風險，儘管樂觀鎖定大部分時間都適用。
但是，您應該只更新更新的字段。如果你對錶上不同的數據項有這樣的單獨需求，你應該寫專門的數據訪問這些更新例程。
的好處是，你只需要數據從/到數據庫，這將減少延遲和網絡上，客戶端和數據庫負載轉移。
您在當前解決方案擴大時更新，並登錄在同一時間正在發生時，可能會遇到問題。如果您使用鬆散的SELECT *語句，登錄的性能可能會降低，否則您甚至可能會面臨鎖定。
如果更新經/緯度是從多個源完全動態的，你應該考慮將其存儲在一個新的表，甚至可能使每次更新的新行。如果多個源不斷更新同一行，您肯定會面臨性能/鎖定問題。創建新行似乎違反直覺，但它可以讓您幾乎同時從多個來源導入數據，並使用時間戳或類似的方式查詢數據以查找最新更新，同時仍然保持更新查詢非常精簡和快速。通過時間戳可以自動快速修剪。
每個用戶只會更新一行，並且只有該用戶（即一個設備）將更新該行 - 所以不應該存在任何鎖定問題。 – Wilka 2011-03-30 08:57:56
根據訪問該數據庫的應用程序的使用，你可以，如果你打算經常更新單個記錄遇到鎖定問題。此外，爲了理智，維護和可擴展性，您可能需要查看normalization。
如果您更新的列是集羣索引的一部分（假設存在），那麼您將爲SQL Server造成相當多的開銷，因爲它會重新排列表/索引結構以維護聚類序列。如果它們是非聚集索引的一部分，則會導致維護索引結構的開銷。
在這兩種情況下，統計數據也都會發揮作用。您的統計信息可能會過時，從而導致查詢/存儲過程出現次優執行計劃：您可能會以比其他方式更頻繁地運行更新統計信息。不參與指數
更新固定長度列應該在的地方發生，因爲數據行的大小不會改變。更新不參與索引的可變長度列或可空列會隨着數據行長度的改變而導致頁面拆分（更不用說由頁面拆分引起的索引維護開銷）。
如果您使用當前值覆蓋LAT/LON，那麼您將失去潛在的有價值/有用的數據。好，我認爲，簡單地插入新行到PersonLocation表：
id autoincrementing integer
personid int fk references persons(id) [indexed non-unique to speed queries on person location history)
lat float
lon float
asof datetime default getdate()
編輯：如果你需要經常得到當前的位置，你可以考慮在指數（PERSONID，日期時間）。
+1某些地方有一些法律規定，如果數據庫中存在頻繁變化的信息，最終用戶將需要歷史記錄。 – 2011-03-29 20:56:55
只要存在可用於此時間序列信息的商業用途並且只要存儲空間不是問題，這就是一個很好的建議。 – 2011-03-29 20:56:57
@Joel：浮點數和整數不佔用太多空間，而且數據的實用性在今天並不總是很明顯。但是可能會有比OP的想法更多的用戶，所以你的觀點很好。我假設用戶在跟蹤當前位置時沒有問題，所以位置歷史記錄也沒有問題。其他好的建議是獲得用戶的權限來跟蹤他們的位置。 – Tim 2011-03-29 21:00:24
每天10,000次更新不是您永遠不必擔心的事情。一分鐘10000更新可能開始成爲一個問題。對數據庫進行建模以保持簡單，並且不要因爲性能原因而使用模型。 Oded關於只更新正在更改的列的建議是正確的，無論您的更新量是多少，因爲無論您更新的頻率如何，您仍然希望尊重帶寬。
我知道這並不完全回答這個問題，但是是否需要這麼多的寫入請求？您是否可以不使用某種形式的差異觸發來編寫是否幫助減少工作量？ – Hawxby 2011-03-29 20:45:05
@Hawxby，這是一個很好的觀點。希望這會很快發生在我身上:)無論我決定做什麼，我都會這樣做。 – Wilka 2011-03-29 21:07:18