我正在設計一個程序，用戶在數千人（或潛在的數百萬人）上做出單一選擇。我想到了兩種方法將它存儲在數據庫中： 1）爲每個條目單獨一行 2）單個長文本，只爲新人添加選擇或修改現有人的選擇。長文本或成千上萬行，或者別的什麼？
我想像每個條目的單獨行應該更有效率，但是如果我們談論的話，成千上萬的條目，那麼我正在查看的網絡開銷是什麼而不是僅僅返回一個長文本並使用用戶的cpu來解析文本？
舉個例子，一個長的文字可能是這樣的：
Data
[Person A:Choice A][Person B: Choice A][Person C: Choice C]...[Person n:Choice n]
而多行顯然將是：
Person Choice
A A
B A
C C
....
n n
也許我不是在正確的道路這種思維首先。有沒有更有效的方式來做這樣的事情？
感謝您的輸入。
我會把我的意見放在一個答案，並擴大在地方。
關於您的決定string vs Table。表每次。
基於表Person (Id, Name)，表Choice (Id, Value)和表PersonChoice (Id, PersonId, ChoiceId)的設計。會給你一個可轉位，可搜索和靈活的解決方案。
在SQL文本列中隱藏數據是一個非常糟糕的主意 - 顯然忽略了數據及其數據類型XML。但這並不適用於此。
稍後添加統計信息的一種解決方案可能是讓計劃的SQL代理作業運行數據解析什麼以及何時進行更改並將數據存儲在單獨的「報告」表中。
在您的設計中需要考慮的事情 - 爲了節省自己必須存儲和處理數千行 - 是將選擇分組在一起的想法。可以爲你節省大量的工作（無論是你自己還是服務器）。
歡迎來到數據庫設計的世界！
我只是建議您將Id從PersonChoice表中取出，因爲表格的PK將是PersonId，ChoiceId，並將每個Id的FK都分配給它們各自的表格。 只是一個小小的建議，像我說的 – Qpirate
我想像的不同行的每個條目應該是更有效，但如果 我們談論的，比方說，幾十萬項， 那麼什麼是網絡開銷我在看查詢該 而不是隻返回一個長文本，並使用用戶的CPU到 解析文本？
網絡開銷（作爲兩種設計之間的差異）可以忽略不計。基本上你發送給服務器的所有內容都是你的查詢，所有服務器返回的都是結果集。如果查詢的結果是一行，則服務器只返回一行。如果查詢的結果是10,000行，則服務器發回10,000行。
真正的開銷是執行速度服務器上和維護。如果您使用索引，服務器將快速在表中找到索引行。但是，像「1,2,3,5,6,7,8,10,13,17,18,30,27」這樣的單個值中找到17可能不會使用索引。
值一樣，也失去類型安全和使用外鍵引用和級聯的能力。
表每次。表'Person'，表'Choice'，表'PersonChoice'包含每個表格的Ids，顯示所做的選擇。可索引，可搜索，靈活。 – Paddy
我想我還應該補充說，用戶將有能力看到他/她的全部統計信息，以便對每個人進行選擇，所以我將不得不訪問所有用戶的選擇。你會在這種情況下推薦桌子嗎？ –
當然，在SQL中的文本列中隱藏數據是一個非常糟糕的主意。要節省1000行，可能需要調查選擇組，以減少行數？有人會很快就會把這個論點比我簡潔得多！ – Paddy