2009-05-26 116 views
2

我使用表GadgetData在我的应用程序中存储小工具的属性。小工具基本上是一种自定义控件,它具有80%的属性,如高度,宽度,颜色,类型等常见的属性。每种小工具类型都有一些独特的属性集。所有这些数据都必须存储在数据库中。目前我只存储通用属性。我应该使用什么样的设计方法来存储这些数据在哪些列是动态的。SQL Server动态列问题

  1. 创建具有公共属性的表作为列并添加Text类型的额外列以存储XML格式的每个小配件类型的所有唯一属性。
  2. 创建一个包含所有小工具类型中所有可能列的表格。
  3. 为每种类型的小工具创建单独的表格。
  4. 您推荐的其他更好的方法吗?

(注:小工具类型的数量可能增长甚至超越100)

回答

3

选项3是一个非常规化的选项,但如果您必须跨多种类型进行查询,则会返回并咬你 - 如果添加了新类型,每个SELECT将会有另一个连接。维护噩梦。

选项2(稀疏表)将有很多NULL值并占用额外的空间。如果未来添加其他类型,表格定义也需要更新。不是很糟糕,但仍然很痛苦。

我在生产中使用选项1(使用xml类型而不是text)。它允许我序列化从我的通用类型派生的任何类型,提取公共属性并在XmlProperties列中保留唯一属性。这可以在应用程序或数据库中完成(例如存储过程)。

0

根据“小玩意”是多么的不同,我不会喜欢选择2会有一个漂浮在很多空的,如果你有一个必须使用一个小工具但不能用于另一个小工具的列,这可能会变得很糟糕。

如果小部件的数量很少发生变化,我只会选择3,因为每次都需要更改数据库。

未提及的选项是将小工具与包含小工具唯一值的子表一起存储。但是这需要大量工作来返回小工具细节或多个数据库调用。

离开选项1,除了我会使用SQL服务器XML类型而不是文本,您可以在存储过程中使用XQuery。

1

您的选择:

  1. 好的。甚至可以强制架构等
  2. 你不能让那些列NOT NULL,所以你会失去一些数据的完整性
  3. 只要你不允许搜索多一种类型的小工具,这是够好,但选项1是更好
  4. 我会使用ORM

注:

如果你想保持你的数据库“关系”,但并不害怕使用ORM工具,那么我会用一个。在这种情况下,您可以根据需要(几乎)存储数据,但只要正确映射它们就能正确处理数据。 见:

如果您只需要SQL的解决方案,然后根据你的RDBMS,我可能会使用XML列来存储所有特定于数据小工具类型:您可以进行验证,轻松使用新属性进行扩展。然后,您可以将所有内容放在一张表中,快速搜索所有常见属性,并且还可以轻松搜索一个小工具的类型属性。

1

如果所有类型的小工具都有许多可以存储在一个表中的通用强制属性以及几个可选属性,您最好使用第一种方法:因此,您将使用最好的关系模式,并通过XML减轻您的生活。不要忘记使用XML Schema集合将XML列链接到它:您将拥有完整的索引和XQuery功能。

如果小工具类型有非常不同的描述和5个或更多不同属性集合中只有1-3个公共列,请使用第3种方法。


但关于100+类型的小工具我会用第1方法的情况:它具有良好的性能和易用性的支持和进一步发展的支持的灵活性。