數據庫設計

Question

我有4個表： users ， posts ， categories ， categories_map

posts具有id ， text ， category_id
categories_map包含user_id和category_id

我的目標是讓用戶可以預覽隊列。 同樣，用戶將能夠跳過某些帖子或在其中編輯文本。 如果用戶跳過了一個帖子，它將永遠不會出現在隊列中。 但是，用戶無法更改順序，因為cron將執行腳本。

我認為的第一種方法是創建一個包含user_id ， post_id ， text_modified ， is_skipped ， last_posted 。 因此，當執行cron作業時，它將留下一個時間戳，以便下次不會捕獲該帖子，並且用戶可以輕松更改該帖子的文本。

第二種方法是創建一個單獨的表，在該表中將為用戶user_id ， post_id ， category_id ， text_modified生成隊列。 因此，cron作業可以輕松地按照此表進行作業，並在完成后刪除該行。 但是如果使用這種方法，如果我將擁有30個用戶，平均每個用戶包含5000個帖子的3個類別，那么我的表將已經有450000行。 是的，如果索引正確，應該一切都很好。 但是，當我有100-200個用戶時，它可以擴展嗎？

我應該采用哪種方法，或者還有其他解決方案？

Answer 1

很多事情取決於您的產品。 我們不知道：

1. 用戶之間如何交互？
2. 是否必須堅持他們的行動（跳過），或者如果他們在99.9個百分點以上失去他們的行為，我們可以嗎？
3. 是他們對帖子的文字修改，全局可見還是僅對他們可見。
4. 用戶是否按類別檢查帖子？

說完所有這些未知數后，我將對其進行刺殺：

• 如果問題4的答案為“是”，那么從您的PK來看，選項＃2聽起來更合理。
• 如果問題4的答案為“ 否”，那么從您的PK來看，選項1聽起來更合理。

對於數據庫大小，我認為您正在做一些預優化。 您應該考慮表格寬度。 由於您的表格非常狹窄（只有幾列，主要是整數），因此您不必擔心特定表格的長度。

當這成為一個約束時（您可以對其進行基准測試或等待查看特定服務器上的磁盤空間），可以通過輕松地對用戶分片來擴展數據庫。 您基本上將不同的用戶放在不同的數據庫服務器上。

• 注意：問題1將決定上述操作的難易程度 。

說了這么多，請記住性能影響：

1. 列表會變得很長。
2. 如果用戶修改影響其他用戶，則您將不得不進行大量扇出工作，以將更新發布到特定隊列。

在這種情況下，您可能需要查看一些分布式緩存，例如Memcached，Redis。

• 注意：根據對問題2和3的回答，您甚至可能不需要保留隊列。