可擴展性：設計消息表

這個問題可能非常簡單，但我想確保我走的是正確的道路，而不是犯任何簡單且不可逆轉的錯誤。

我的項目將基於消息傳遞，它不會像 Twitter 或 Facebook 那樣使用較少（不是說它們沒有被使用，但它不是呈現給使用者的關鍵選項）

我想知道一個簡單的桌子設計會像;

• 來自 (id)
• 到 （身份證）
• 內容 （文字）
• created_at （日期）
• isRead （布爾值）

就足夠了，因為即使它計劃是一個小項目，我也不認為所有消息都應該儲存在一個表中，並且對於每個使用者想要查看他們的消息歷史記錄時，我不應該掃描整個表這樣做。我正在考慮這種結構的可擴展性以及使用像 mongoDB 這樣的NoSQL DB 將如何受益。

您可以通過以下嵌入的 json 文件來實現您的消息收集，並可以確保“mail_id”鍵上的索引以避免掃描所有文件。為了您的資訊，這裡的集合用作表格，每個文件都用作表格的行。

{
mail_id:string
sentMails:{
           [
               {
               sent_at: datetime,
               subject: string,
               sent_to: string,
               cc_to:[array of mailid strings],
               bcc_to:[array of mailid strings],
               attachments:[
                               {
                               attachment_name:string,
                               attachment_type:strng
                               }
                           ],
               sent_mail_content: string               
               }
           ]
           }

receivedMails:{
               [
                   {
                   received_at: datetime,  
                   subject: string,                
                   received_from: string,
                   cc_to:[array of mailid strings],
                   attachments:[
                                   {
                                   attachment_name:string,
                                   attachment_type:strng
                                   }
                               ],
                   received_mail_content: string
                   }
               ]   
           }
}

我希望它會有所幫助。

說到這裡的 MongoDB 方面，有很多方法可以解決這個問題，而且很大程度上取決於您希望如何擴展它，如果您希望達到文件大小限制等，這會影響什麼你需要的索引，你是否應該計劃分片，你應該選擇什麼分片鍵等等。因此，許多排列。

我可以通過使用 MongoDB 來完成這類事情的最常見方法，優點和缺點，但幸運的是，有人已經為我做到了（有圖片！）。當然，它適用於收件箱應用程序，但理論和問題基本上保持不變：

http://www.10gen.com/presentations/data-modeling-examples-real-world-0

看一下這個展示文稿，它顯示了在提出適合您的應用程序的數據模型時必須做出的一些決定的含義。

引用自：https://dba.stackexchange.com/questions/45894