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