存儲非常細微的用戶首選項

Question

我在這裏看到了關於存儲用戶首選項的幾個問題，但他們似乎主要是指最基本的一組首選項。我目前正在研究一個高度可定製的網絡應用程序，這將需要存儲大量的偏好，我正在努力如何存儲它們。

我要存儲的偏好類型包括用於顯示特定工具提示的布爾值，在頁面上排列各種內容面板，登錄後顯示哪個頁面，特定表單字段的默認值等。全部通用，我預計每個用戶將會有50多種這種類型的偏好，這些數據主要是布爾值和整數。

我不是一個很熱衷於序列化的人，但我關心將每個首選項存儲爲單獨行的可擴展性。思考？

Answer 1

序列化數據blob是這裏的方法，但不是出於性能原因 - 而是因爲這是系統的一個方面，可能會看到大量的變化。您不想僅僅因爲您需要允許首選項在某個頁面上打開高級模式就更改數據庫模式。

HLGEM提到的實體屬性值模型適合於從「易於演變」的角度來看，但正如他所說的那樣，它的性能會很差。

你會放棄序列化對象的能力是直接查詢數據庫的用戶匹配的特定模式（也許你正在追蹤一個錯誤，只會出現一些組合的設置，你想看到如果你有任何組合的用戶）。

Answer 2

無論你做什麼，除非你想要一個性能很差的系統，否則不要使用這個實體-ttrivute-value結構（http://en.wikipedia.org/wiki/Entity-Attribute-Value_model）。調用一個50列的表格要比調用一個表格要快50倍，你必須加入50個表格才能獲得所需的所有信息。

我會根據您希望如何查詢首選項（如果您想要全部重新啓用），爲每個常規組首選項（登錄首選項，整體站點首選項，特定頁面或功能首選項）創建相關表登錄會在登錄時拉動整個站點所需的內容，當用戶點擊這些內容時需要特定區域的內容，以及它們的某種組合），並且在其中設置用於首選項類型的布爾列。這樣，您對網站每個區域的所有偏好設置將位於同一個表格中，或者最多兩個或三個表格，因此獲取信息相對容易。這是設計對性能至關重要的一個地方（你會一直在查找偏好，所以即使毫秒數也是如此），所以你應該首先考慮設計中的性能。在這裏比任何希望使它看起來像面向對象或爲開發人員創建更少的工作都重要得多。

Answer 3

我不知道我是否會將用戶喜好等信息存儲在數據庫中。看起來，用戶登錄後你會希望查看很多（如果不是全部的話）用戶首選項;如果你最終做了一堆數據庫查詢，你的系統最終會很慢。相反，我建議將用戶的所有設置保存在單個文件（或某處的單個記錄）中，並在用戶登錄後將其批量吞併並緩存。

Answer 4

假定用戶數據已存儲在數據庫中，我沒有看到任何真正的問題存儲在一行中，特別是如果你可能需要根據數據進行查詢。選擇所有優先A或B等的用戶。

雖然我會將它加載到類中，並通過某種緩存機制來保存該類。

Answer 5

如果您不需要在首選項上進行搜索，則可以始終將首選項存儲爲XML並將其保存到「首選項」列。應該使未來更容易添加新的偏好;）

Answer 6

你可以做的另一種選擇（如果你不需要你的項目存儲在數據庫中，例如檢查統計數據（誰做什麼等） ），你可以把他們所有的設置放在一個cookie中並存儲在他們的機器上。

當然，與餅乾來使用cookie的所有注意事項。但只是另一個想法...

Answer 7

用戶喜歡更多的喜好（所有的動物是平等的，但有些比其他人更平等）。這些應該專門針對登錄界面上的檢索和應用進行優化。隨着優先級降低，可以使用任何標準將它們聚合在一起，並可能將其另存爲單獨的列（例如，字體首選項列包含字體類型，大小和顏色並引用字體表）。同時使用db工具對重度使用的列進行索引，並重新設計以拆分聚合列，以便可以確定聚合中的哪個元素需求量很大。

總的來說，用戶偏好往往是非常靜態的（即像習慣一樣），不要混淆更偏好於用戶偏好的數據。