需要幫助應用程序設計

Question

所以，我喜歡關於設計類和存儲以下情況的數據的最佳方法的一些反饋：

我有一個名為Tasks的接口，如下所示：

interface ITask
{
    int ID{ get; set;}
    string Title {get; set;}
    string Description{get; set;}
}

我希望能夠創建不同類型的任務，具體取決於誰在使用該應用程序...例如：

public class SoftwareTask: ITask
{
    //ITask Implementation
    string BuildVersion {get; set;}
    bool IsBug {get; set;}

}

public class SalesTask: ITask
{
    //ITask Implementation
    int AccountID {get; set;}
    int SalesPersonID {get; set;}
}

所以我看到它的方式我可以在數據庫中使用與ITask接口匹配的列創建一個Tasks表，並在一列中推送更具體任務的所有屬性（甚至可以將任務對象序列化為單個列）柱）

要么

為每個任務類型創建一個表，以存儲該類型唯一的屬性。

我現在真的不喜歡任何一種解決方案。 我需要能夠創建不同類型的任務（或任何其他類），它們通過基本接口共享一組共同的核心屬性和方法，但能夠以易於搜索的方式存儲其獨特屬性並過濾而不必為每種類型創建一堆數據庫表。

我開始研究插件架構和策略模式，但我沒有看到哪里可以解決我存儲和訪問數據的問題。

非常感謝任何幫助或推動正確的方向！

Answer 1

你可能應該從ORM如何處理這個問題，比如TPH / TPC / TPT

鑒於ITask是一個接口，你應該選擇TPC（每個混凝土類型的表）。 當你把它作為基類時，TPT和TPH也是選項。

Answer 2

您的第二種方法（每種類型一個表）是解決此問題的規范方法 - 雖然它需要更多的努力來實現它，它更適合大多數數據庫的關系模型，並保留數據的一致和有凝聚力的表示。 每種具體類型使用一個表的方法效果很好，並且與大多數ORM庫（如EntityFramework和NHibernate）兼容。

然而，當子類型的數量非常大或者在運行中創建子類型時，有時會使用幾種替代方法。

備選方案＃1：鍵值擴展表。 這是一個表，每個附加的數據字段需要存儲一行，一個外鍵返回核心表（Task），以及一個指定這是哪種字段的列。 它的結構通常類似於：

TaskExt Table
=================
TaskID     : Number (foreign key back to Task)
FieldType  : Number or String (this would be AccountID, SalesPersonID, etc)
FieldValue : String  (this would be the value of the associated field)

備選方案＃2：類型映射擴展表。 在此替代方法中，您創建一個表，其中包含一組可以為不同數據類型（數字，字符串，日期/時間等）的可為空的列，其名稱如DATA01，DATA02，DATA03 ......等等。 對於每種任務，您可以選擇列的子集並將它們映射到特定字段。 因此，DATA01可能最終成為SoftwareTask的BuildVersion和SalesTask的AccountName。 在此方法中，您必須在某處管理某些元數據，以控制將特定字段映射到的列。 類型映射表通常類似於：

TaskExt Table
=================
TaskID   : Number  (foreign key back to task)
Data01   : String
Data02   : String
Data03   : String
Data04   : String
Data05   : Number
Data06   : Number
Data07   : Number
Data08   : Number
Data09   : Date
Data10   : Date
Data11   : Date
Data12   : Date
// etc...

---

選項＃1的主要好處是您可以根據需要動態添加任意數量的不同字段，甚至可以支持一定程度的向后兼容性。 然而，一個重要的缺點是即使是簡單的查詢也會變得具有挑戰性，因為對象的字段被轉移到表中的行中。 Unpivoting原來是一個既復雜又往往表現不佳的操作。

選項＃2的好處在於它易於實現，並且在行之間保持一對一的對應關系，使查詢變得容易。 不幸的是，這也存在一些缺點。 第一個是列名完全沒有信息，你必須引用一些元數據字典來了解哪些列映射到哪個類型的任務的字段。 第二個缺點是大多數數據庫將表上的列數限制為相對較小的數字（通常為50-300列）。 因此，您只能使用這么多數字，字符串，日期時間等列。 因此，如果您鍵入的最終日期時間字段多於表支持，則必須使用字符串字段來存儲日期，或者創建多個擴展表。

預先警告，大多數ORM庫不提供對這些建模模式中的任何一種的內置支持。