目前我有一個表用戶，一個表聊天，但是我希望有“群聊”和“私人聊天（dm）”。群聊比私聊需要更多的資料，例如：群名，圖片，......
解決這個問題的最佳方法是什么？我是否進行 1 表聊天，并在其中放置一個型別屬性來確定它是否是私人聊天，如果是私人聊天，則將某些列留空。或者我會制作 2 張桌子，一張用于私人聊天，一張用于群聊嗎？
uj5u.com熱心網友回復：
這與一般問題“您是否應該將敏感列拆分到一個新表中”類似，一般答案是相同的，這在很大程度上取決于您的資料訪問代碼和安全框架。
第三種選擇呢，為什么不將Private Chata 建模為Group Chat組中只有 2 名成員的 a 呢？有時將模型拆分為這些型別是過早的優化，尤其是在聊天風格應用程式的背景關系中。例如，私人聊天難道不能像群聊一樣從影像中獲益嗎？能夠為自己的私有組指定組名對用戶來說不是有好處嗎？
如果只有一種聊天型別并且由用戶決定可以加入多少人或者其他人是否可以加入聊天，您會發現應用程式的整個開發和管理要簡單得多。
如果您仍然想探索這兩種概念型別，這是一個可能會給您一些間接見解的答案：https ://stackoverflow.com/a/74398184/1690217但最終我們需要更多資訊來證明選擇一種結構而不是其他。性能、安全性和一般資料治理是對實施有影響或強加警告的一些考慮因素。
從結構的角度來看，您的Group Chats和Private Chats都可以是公用Chat表的實作，從概念上講，我們可以說這兩種形式都繼承自Chat.
在關系資料庫中，我們有 3 個通用選項來建模繼承：
- 每個層次結構的表 (TPH)
使用帶有鑒別器列的單個表來確定每一行的特定型別是什么。然后在您的應用層或通過視圖您可以查詢每個型別和場景需要的特定欄位。- 在TPH中，基本型別通常是抽象型別定義
每個型別的表 (TPT)基本型別和每個具體型別作為它們自己單獨的表存在。來自繼承表的 FK 是 PK，與基表中的相應記錄共享相同的 PK 值，創建 1:0-1 關系。這需要一些稍微復雜的資料訪問邏輯，但它使得Private Chat在Group Chat背景關系中意外檢索 a 變得更加困難，因為需要從正確的表中顯式查詢資料。- 在TPT中，基本型別本身就是具體型別，資料記錄根本不必繼承到擴展型別中。
- 簡單的隔離表 （模式中沒有繼承）
這通常是最簡單的方法，如果您的表在應用程式邏輯中確實具有繼承性，那么公共屬性將在每個表中復制。這會導致大量冗余的資料訪問邏輯，但是遵循DRY原則的應用層 OO 繼承解決了大部分代碼冗余問題。
How can you represent inheritance in a database?這個答案 從更學術和研究的角度涵蓋資料庫繼承。
從性能的角度來看，如果使用模式明顯不同，則隔離作業負載有好處。因此，如果Group Chats有不同的使用組態檔，查詢的頻率或型別明顯不同，或者中的其他欄位Group Chat將從它們自己的索引組態檔中受益，那么拆分表將允許您的資料庫引擎提供更好的索引管理和執行計劃優化由于更準確地捕獲表統計資訊。
從安全性和合規性的角度來看，單表實作 ( TPH ) 可以減少資料訪問邏輯，從而減少代碼的整體攻擊面。但是一個好的 ORM 或代碼生成策略通常可以緩解這個領域可能出現的任何問題。相反， TPH或簡單表可以更輕松地定義資料庫或架構級別的安全策略和約束。
最終，哪種解決方案最適合您將取決于實施和維護您選擇的應用程式邏輯所需的作業量。
我有時會在同一個資料庫中混合使用TPT和TPH ，但如果我需要在資料模式中繼承，我通常會傾向于使用TPT ，這篇舊文章解釋了我反對TPH的理由：資料庫設計：關于約束的鑒別器與分離表。我的一般規則是，如果型別需要是多型的，要么考慮兩種型別，要么型別背景關系在應用程式運行時以某種方式動態變化，那么TPT或無繼承更容易實作。我用TPH當型別之間的差異很小并且預計在應用程式生命周期內不會合理地差異太大時，以及當使用和實作將非常相似時。
TPT提供了一種表達繼承的方式，同時也維護了一個非常不同的行為或互動的分支（在基本實作之上）。許多TPT實作看起來好像它們也可能是單獨的表，在選擇這種架構模式時，限制記錄之間 1:1 鏈接的愿望通常是一個強有力的決定因素。考慮此模型的一個好方法是，即使您不在應用程式邏輯級別使用繼承，您也可以擴展基本記錄以包含任何繼承型別的元資料和行為。事實上，使用 TPT 很難限制資料記錄，這樣你就不能擴展到多個型別。
- 由于這個限制，TPT 通常可以從應用層建模為根本不使用 OO 繼承
- TPT補充組合繼承
TPH通常是對實作簡單繼承的域模型進行建模的默認方法，但是如果您需要更改型別或與單個記錄可以是兩種型別的想法不兼容，這會在應用程式邏輯中引入問題。對此有簡單的解決方法，但從歷史上看，從代碼維護的角度來看，這會導致問題，這確實是概念沖突，TPH 更符合繼承而不是組合
在Chat的背景關系中，TPT可以從組合的角度作業。所有聊天都具有相同的基本功能和互動，但Group Chat記錄可以具有擴展的元資料和行為。除非你設想有很多自己的特定實作，否則如果實作沒有差異，就沒Private Chat有理由將 的基本概念擴展Chat到實作。Private Chat
出于這個原因，是否有必要從資料庫的角度區分私人聊天和群聊？在任何一種情況下，您的應用程式運行時都不應該使用盲SELECT * 式查詢來訪問資料，它應該請求給定背景關系所需的特定欄位，無論您是使用表中的欄位還是表的名稱來區分不同的概念不如能夠證明這些概念的存在或它們之間的差異重要。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/534212.html
標籤：数据库数据库数据库猫鼬
上一篇：聚合函式Mongoose-節點
下一篇：Mongoosev6.2.7新的Model.save()方法無法正常作業在try-catch中嘗試了promise、回呼和異步等待，但沒有任何效果