在数据库中存储具有公共基类的对象

Question

假设我有一个通用的基类/接口

  interface ICommand
  {
    void Execute();
  }

然后有几个命令继承自这个接口。

  class CommandA : ICommand
  {
    int x;
    int y;
    public CommandA(int x, int y)
    {  ...  }
    public void Execute () { ... }
  }
  class CommandB : ICommand
  {
    string name;
    public CommandB(string name)
    {  ...  }
    public void Execute () { ... }
  }

现在我想用一种通用方法将这些命令存储在数据库中，然后将它们从数据库中全部加载到List<ICommand> 并执行它们的执行方法。

现在我在数据库中只有一个名为 commands 的表，在这里我存储了对象的字符串序列化。基本上表中的列是：id|commandType|commaSeparatedListOfParameters。虽然这非常简单，并且适用于加载所有命令，但如果不使用子字符串和其他晦涩的方法，我就无法轻松查询命令。我想有一个简单的SELECT id,x,y FROM commandA_commands WHERE x=... 方法，同时有一种从命令表中加载所有命令的通用方法（我想这将是 commandA_commands、commandB_commands 等的某种 UNION/JOIN）。

添加新命令不需要在数据库中进行太多手动操作或手动创建序列化/解析方法，这一点很重要。我有很多，并且一直在添加和删除新的。我不介意创建命令+表+查询生成工具，但如果这是最佳解决方案所必需的。

我能想到的最好的就是像id|commandType|param1|param2|param3|etc.. 这样的普通表，它并不比我当前的解决方案好多少（实际上更糟？），因为许多命令都需要空参数并且数据类型会有所不同，所以我有再次求助于普通的字符串转换，并将每个字段的大小设置为足够大以容纳最大的命令。

数据库是 SQL Server 2008

编辑：在这里找到类似的问题Designing SQL database to represent OO class hierarchy

Answer 1

您可以使用 ORM 将命令继承映射到数据库。例如，您可以使用 ORM 提供的“按层次结构表”技术（例如：实体框架、nHibernate 等）。当您检索它们时，ORM 将实例化正确的子类。

这是一个先在实体框架代码中执行此操作的示例

abstract class Command : ICommand
{
   public int Id {get;set;}

   public abstract void Execute();
}

class CommandA : Command
{
   public int X {get;set;}
   public int Y {get;set;}

   public override void Execute () { ... }
}
class CommandB : Command
{
   public string Name {get;set;}

   public override void Execute () { ... }
}

请参考 EF 4.1 Code First Walkthrough 以使用 EF 配置此模型。

如果您的命令采用完全不同的参数集，您可以考虑使用“每个类型的表”继承建模。在这里，由于涉及到大量的联合和表连接，您将付出一些显着的性能损失。

另一种方法是将命令参数存储为 XML 配置，您可以在其中手动（反）序列化。这样，您可以将所有命令保存在一个表中，而不会牺牲性能。同样，这有一个缺点，您无法使用命令参数进行过滤。

每种方法都有其优点和缺点。您可以选择适合您要求的策略。

Answer 2

这个问题很常见，我还没有看到没有缺点的解决方案。在数据库中准确存储对象层次结构的唯一选择是使用一些 NoSQL 数据库。

但是，如果要求使用关系数据库，我通常会采用这种方法：

• 基类/接口的一个表，用于存储所有类型的通用数据
• 每个降级类一个表，它使用与基表完全相同的主键（顺便说一句，这是 SQL Server 2011 序列的一个很好的用例）
• 一个包含将要存储的类型的表
• 将所有这些表连接在一起的视图，以便轻松加载/查询对象

在你的情况下，我会创建：

• 表命令库
  • ID（int 或 guid）- 命令的 ID
  • TypeID (int) - 命令类型的 ID
• 表命令A
  • ID（int 或 guid）- 与 CommandBase 表中的 ID 相同
  • X（整数）
  • Y（整数）
• 表命令 B
  • ID（int 或 guid）- 与 CommandBase 表中的 ID 相同
  • 名称（nvarchar）
• 表命令类型
  • ID (int) - 命令类型的 ID
  • 名称 (nvarchar) - 命令类型的名称（“CommandA”、“CommandB”、...）
  • TableName (nvarchar) - 存储类型的表的名称 - 如果需要一些动态 sql 很有用 - 否则可选

• 查看命令，类似于：

  select cb.ID, a.X, a.Y, b.Name 
   from CommandBase cb
     left outer join CommandA a on a.ID = cb.ID
     left outer join CommandB b on b.ID = cb.ID
  

这种方法的好处是它反映了您的班级结构。它易于理解和使用。

缺点是当你添加新类时会变得越来越麻烦，很难建模超过一层的层次结构，如果有很多后代，视图可能会长一英里。

就个人而言，如果我知道子类的数量相对较少且相对固定，我会使用这种方法，因为它需要为每个新类型创建（和维护）一个新表。但是，该模型非常简单，因此可以创建一个工具/脚本来为您创建和维护。

Answer 3

我们越来越多地在 SQL 中使用 XML 来处理我们的软数据。查询（使用 XPath）可能会有点痛苦，但它允许我们存储每行的元数据、针对模式进行验证等。

然后可以通过代码解析 XML，并且可以通过反射将参数匹配到反序列化对象中的参数。

这有效地复制了 ORM 功能，但具有扁平的数据库结构，简化了查询，甚至可以通过 XPath 查询参数。

记住孩子们，观点是邪恶的。