最近在設計一些復雜的 MySQL 數據庫表。碰到一些需要存儲用戶所得成就、用戶所得稱號、用戶消息之類的數據的需求。感覺這類數據其實可以直接用 JSON 格式存儲在 user_meta 表的 text 類型字段里。而不需要設計過于復雜的表。當然并不是所有數據都存儲在一起，可能按照 100 條數據/條記錄的方法。優點是：每頁顯示 50 條用戶數據的話，每頁只要讀一次數據庫的一條記錄就行了，而不需要遍歷 50 條記錄。把數據庫的壓力分擔到程序執行上，貌似更多情況是數據庫壓力過大導致網站掛掉。不需要設計復雜的數據庫表，因為這類數據的結構可能經常變動，用 JSON 可以在程序中做好處理。但是我不知道這樣設計的缺點，因為我沒有足夠的經驗。麻煩大家了，謝謝 =w=
2 回答
寶慕林4294392
TA貢獻2021條經驗 獲得超8個贊
既然不需要索引，這種情況看起來用KeyValue庫更合適一些，比如TC/TT, Bdb, Redis；或者MongoDb這種文檔型數據庫也可以（但也有很多設計上的坑）。
其他理由如下：
1. Mysql庫里慎用text字段，性能不樂觀……
2. 一旦需要對這些數據進行索引或者統計，從MySQL中解出所有的數據并重新入庫成本相當巨大……
3. 大JSON的parse性能同樣不樂觀，而且對于中文數據，純JSON太占空間了……
4. 100條/記錄的存儲方式，如果需要對其中一條進行增加/刪除/更新，即需要更新整個100條，更新量比較大；同樣可能會產生并發問題，需要自行實現行鎖。
一般情況下，如果你用了關系數據庫，不要輕易（為了性能/空間）做違反范式的設計，除非你有足夠的理由和把握，否則會給未來的維護升級帶來無盡的麻煩。
通常建議：
1. 換Key-Value庫/文檔庫(mangodb)
2. 或者關系庫做好緩存和索引優化，可以把一個用戶相關的勛章稱號都緩存在一個key下，這個是經過被各大網站驗證過無數遍的設計……
泛舟湖上清波郎朗
TA貢獻1818條經驗 獲得超3個贊
我的個人建議, 無需一開始就使用key/value數據庫, 但是將mysql設計的可以輕易的用kv數據庫代替, 以提高數據庫PAYLOAD部分的吞吐能力. 而在INDEX部分, B Tree算法沒有過時, mysql就不會過時.
對于mongodb的復雜算法和實現, 我更加傾向于memcachedb/redis這種一句話就可以講清楚自己在做什么的數據庫方案.
總之, 解決問題的思想無需被范式捆綁.
多看一看別人怎么做的, 你的奇思妙想可能已經不是獨一無二的了.
添加回答
舉報
0/150
提交
取消