6

我想创建一个产品目录，允许目录中每种产品类型的复杂细节。产品类型具有与之关联的截然不同的数据；有些只有通用数据，有些有一些额外的数据字段，有些有许多特定于该产品类型的字段。我需要轻松地将新产品类型添加到系统中并尊重它们的配置，并且我喜欢关于如何为这些产品设计数据模型以及如何处理持久性和检索的提示。

有些产品将非常通用，我计划使用通用 UI 来编辑这些产品。具有与之关联的可扩展配置的产品将获得为其编辑创建的新视图（和控制器）。我希望所有定制产品都定义自己的模型，但共享一个公共基类。基类将表示没有自定义字段的通用产品。

需要处理的示例产品：

  1. 通用产品
    • 描述
  2. 灯泡
    • 描述
    • 类型（包括荧光灯、白炽灯、卤素灯、led 灯）
    • 瓦数
    • 样式（洪水、斑点等的枚举）
  3. 冰箱
    • 描述
    • 制作
    • 模型
    • 样式（在域模型中有一个枚举）
    • 滤水器信息
      • 零件号
      • 描述

我希望使用 MEF 来发现系统中可用的产品类型。我计划创建包含产品类型模型、视图和控制器的程序集，将这些程序集放入 bin 中，并让应用程序发现新的产品类型，并在导航中显示它们。

  1. 使用 SQL Server 2008，存储这些不同类型的产品的最佳方式是什么，允许添加新类型而无需增加数据库架构？

  2. 从数据库中检索数据时，将这些多态实体转换为正确的域模型的最佳方法是什么？

更新和说明

  1. 为了避免内部平台效应，如果每种产品类型都有一个数据库表（用于存储该类型的产品），那么我仍然需要一种方法来检索跨产品类型的所有产品。那将如何实现？

  2. 我与 Nikhilk 就他的 SharePoint 参考进行了更详细的交谈。具体来说，他在谈论这个：http: //msdn.microsoft.com/en-us/library/ms998711.aspx。它实际上看起来很有吸引力。无需解析 XML；并且可以进行一些索引，以允许对数据进行简单快速的查询。例如，我可以通过知道该行中的第一个 int 列是该行代表一个灯泡时的瓦数来说“找到所有 75 瓦的灯泡”。应用层中的某些东西（NHibernate？）将定义从产品类型到用户数据模式的映射。

  3. 否决了具有属性表的模式，因为这可能导致每个产品有很多行。这可能会导致索引困难，而且所有查询基本上都必须对数据进行透视。

4

6 回答 6

2

使用 Sharepoint 样式的 UserData 表，该表具有一组字符串列、一组 int 列等和一个 Type 列。

然后你有一个类型表的列表，它指定了每种类型的架构——它的属性，以及它们在 UserData 表中映射到的特定列。

使用 Azure 和其他实用程序计算存储之类的东西，您甚至不需要定义表。每个 store 对象基本上都是一个字典。

于 2009-02-04T17:08:31.033 回答
1

我认为您需要使用类似的数据模型-

产品表

  • 产品 ID (PK)
  • 产品名称
  • 细节

属性表

  • 属性 ID (PK)
  • 产品 ID (FK)
  • ParentPropertyId（FK - 自引用以对属性进行分类）
  • 属性名称
  • 适当的价值
  • 属性值类型 ID

属性值查找表

  • PropertyValueLookupId (PK)
  • 属性 ID (FK)
  • 查找值

然后有一个基于此的动态视图。您可以使用 PropertyValueTypeId 列来标识类型，使用约定，例如（0-字符串、1-整数、2-浮点数、3-图像等） - 但最终您可以仅存储无类型的所有内容。您还可以使用此列选择控件模板以将相应的属性呈现给用户。

您可以使用值查找表来查找特定属性（以便用户可以从列表中选择它）

于 2009-02-04T06:52:35.503 回答
1

总结一下，让我们看看正在考虑的存储产品信息的选项：1）数据库中的一些 xml 格式

2）类似于上面关于有x个类型定义列的帖子（sharepoint方法）

3）通过具有存储在查找表中的名称和类型定义的通用表以及具有列 id、propertyid、value 的辅助表中的值（类似于＃2，但是这种方法将提供无限的属性信息

4) 上述选项的一些混合，其中产品表将有 x 个公共列（用于存储所有产品共有的属性）和 y 个用户定义的列（这可能是整数类型的 m 和 varchar 类型的 n）。这可能会充分利用#2 和标准化结构，就好像您知道所有产品的所有属性一样。您将获得最常使用的属性（可能是所有产品中常见的属性）的最佳 sql 性能，同时仍允许为每个产品的特定属性自定义列。

还有其他选择吗？在我看来，我认为上述 4 是组合的最佳混合。

  • 戴夫
于 2009-02-09T15:16:26.033 回答
0

将尽可能多的共享预期结构放入传统的规范化 3NF 模型中，然后酌情增加 XML 列。

我看不到 MEF（或任何其他 ORM）能够透明地完成所有这些工作。

于 2009-02-04T06:35:52.510 回答
0

我认为您应该避免内部平台效应并实际为您的专业实体构建表。您将编写特定的代码来管理它们，那么为什么不也有适当的后备表呢？

它会使您的部署稍微困难一些 - 放入一个程序集并运行一个脚本 - 但从长远来看，它可能会为您节省很多痛苦。

于 2009-02-04T07:07:25.067 回答
0

杰夫，

我们目前使用 Products 表中的 XML 字段来处理所有特定于产品的数据。因此，我们的 Products 表有一些所有产品共享的公共字段，一个包含特定产品额外需要的 XML 的 XML，以及一些抓取到 XML 中并将一些经常查询的字段显示为“虚拟”字段的计算字段。 Products 表（例如，“Style”将设置为当前产品定义的任何内容，如果产品没有 Style 属性，则设置为 NULL）。

到目前为止，我们已经非常灵活地使用了这种方法——如果您为 XML 创建了一些不错的 XSD 模式，您甚至可以为这些字段创建 C# 代理类。

对我们来说效果很好 - 加入了关系和 XML 世界的精华。

马克

于 2009-02-04T18:04:09.423 回答