JPA：消息+通知DB架構

Question

所以我建立一個web應用程序的一個辦公室，前端，後端，流動性，客戶賬戶，網上報名，員工帳戶，管理員帳戶......整個九碼。

我的一個主要問題（因爲我沒有這麼做過）是用戶實體交互。 現在我已經定義了4個用戶實體可以與其他用戶交互的方法。

1）消息（和從用戶到...單個或多個用戶）

2）通知（從後端到用戶）

3）任務（和從用戶..至單個或多個用戶）

4）邀請（和從用戶到...單個或多個用戶）

（一個XMPP聊天引擎將被引入，需要記錄，但是那上的後注）

我決定爲每種類型實現一個com協議將是不合理的，所以我創建了一種抽象層（請不要殺了我，但那是我的感受）

因此，在每個用戶將有2所列出

private <Key> Sent_Parcels; 
private <Key> Received_Parcels; 

這些只是數組列表指向包裹實體（抽象層）將包含

private Key Sender; // Key of Sender User Entity 
private List<Key>Recipients; // List of Keys of Recipients 
private Type type; // Enum of Type : Message, Notification, Task, Invitation 
private Key Payload; // Key of the payload object: Message Entity, Notification Entity ... 

現在標準的創建，持久性，通知的東西......不擔心所有，因爲它的一個單一的COM協議，不同的有效載荷...從這一點不關心，因爲我可以通過包裹類型過濾所以...

然而，這裏有一些主要的擔憂（記住大規模實施） ：

1）假設發送方和所有接收方決定刪除的有效載荷。這意味着所有創建的指向這個有效載荷的Parcel Entities都不見了......我如何找到任何人不再需要的有效載荷來刪除它們並在GAE數據存儲上節省寶貴的，昂貴的存儲空間。

2）我很確定在用戶之間實現一個com系統並不那麼簡單，所以如果有關這個主題的專家會出現並告訴我這完全是垃圾，那麼我會很樂意。

3）我選擇這種方法，因爲其具有重複的微小包裹實體，單個有效載荷是更好的是具有重複對在com操作中的每個用戶參與者大的有效載荷（即是完全一樣的）。但是，有重複的有效載荷將意味着，如果用戶刪除它，很好，沒有必要去挖掘誰仍然擁有有效載荷，因爲他是擁有它的唯一實體，另一方面，我覺得它的浪費太浪費了空間

歡迎所有的意見和建議...感謝很多傢伙的一切！

Answer 1

你似乎是重新發明了一種叫做附件和協作軟件;-)

1）考慮實施刪除作爲移動到「垃圾桶」收件人簡化追蹤物品被刪除的電子郵件輪。Blobstore更適合大型「包裹」（附件），爲元數據留下了大量數據存儲空間。

2）不知道你是什麼意思的COM協議。通訊？零件？客戶端 - 服務器鏈接日益流行REST和JSON。渠道將是AppEngine提供實時推送通知的方式。

3）除了像視頻文件這樣的極端，空間比處理時間或帶寬便宜。 NoSQL方法是將數據複製到每個收件人的副本中，以避免查找或加入操作。實施每個收件人存儲配額，以防止其空間使用量無限增長。

Answer 2

儘管我不是一個「com系統專家」，但我可以幫助您處理數據存儲。

你現在正在做的是把一個關係數據模型放到數據存儲中 - >有什麼意義？ 數據存儲在創建「連接」時並不比RDBMS快，實際上，您將不得不花費大部分時間來獲取「關係」。

你需要從取決於你用什麼數據庫系統中的兩個不同的角度看到你的問題：

• 關係數據庫：一個包裹是你的基礎機構，與您共創它與用戶相關聯的關係。當有人刪除包裹時，您只能刪除包裹和用戶之間的「鏈接」。

• 數據存儲區：User是您的基本實體，Parcel僅存在於用戶的角度：發送包裹，收到包裹。把它想象成你的Gmail客戶端：在發件人的「發送郵件」和收件人的「收件箱」中實際上會複製相同的「電子郵件」。如果發件人刪除電子郵件，則不會影響收件人，反之亦然。

在我看來，你是清楚的「SQL」和「NoSQL的」之間的這種怪異的區，我也不會提交到數據存儲沒有關於同樣的老問題深入思考：什麼是你的使用情況？ :)

---

如果你正在做例如WhatsApp或塗鴉

數據存儲面向用戶的即時通訊應用是一個很好的選擇，因爲可擴展性。 您的要點3）是最好的方法：您將需要複製數據，以便您可以快速檢索給定用戶，無需連接。

/** Root entity : user */ 
@Entity 
class User { 
    @Id 
    Key key; 

    @Basic 
    String name; 

    @OneToMany 
    List<UserReceivedParcel> inbox; 

    @OneToMany 
    List<UserSentParcel> sent; 
} 

/** User's child entity : Received parcels */ 
class UserReceivedParcel { 
    @Id 
    Key userReicevedParcelKey; 

    /** Sender key AND duplicate properties to prevent running another query */ 
    @Persistent String senderKey; 
    @Persistent String senderName; 


    @Persistent String parcelType; 
    /** Message data */ 
    @Persistent String messageContent; 
    @Persistent Date sentDate; 
} 

/** User's child entity : Sent parcels */ 
class UserSentParcel { 

    /** Recipient Key AND Attributes */ 
    @Persistent String recipientKey; 
    @Persistent String recipientName; 

    /** ... (message data) */ 

} 

---

如果你正在做一個公司的郵件系統

你可能可能需要運行查詢和有關係，去每一個方向。 Google Cloud SQL（或任何其他RDBMS）實際上可能更適合......特別是因爲可以通過良好的設計來處理規模。不要低估在數據存儲上執行沒有SQL查詢的報告的成本。