SQL Server动态列问题
我使用表 GadgetData 来存储应用程序中小工具的属性。 这些小工具基本上是一种自定义控件，具有 80% 的常见属性，例如高度、宽度、颜色、类型等。每种小工具类型都有一些独特的属性。 所有这些数据都必须存储在数据库中。 目前我只存储常见属性。 我应该使用什么设计方法来存储这种列是动态的数据。
- 创建具有公共属性作为列的表，并添加文本类型的额外列，以 XML 格式存储每个小工具类型的所有唯一属性。
- 创建一个表，其中包含所有小工具类型中的所有可能的列。
- 为每种类型的小工具创建单独的表。
- 还有其他更好的方法推荐吗？
（注：小工具类型的数量甚至可能会超过 100 种并且）
I use a table GadgetData to store the properties of gadgets in my application. There gadgets are basically sort of custom control which have 80% of the properties common like height, width, color, type etc. There are are some set of properties per gadget type that the unique to them. All of this data has to store in database. Currently I am storing only common properties. What design approach should I use to store this kind data where the columns are dynamic.
- Create table with common properties as Columns and add extra column of type Text to store the all unique properties of each gadget type in XML format.
- Create a table with all possible columns in all of the gadget types.
- Create separate table for each type of gadgets.
- Any other better way you recommend?
(Note: The number of gadget types could grow even beyond 100 and )
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
选项 3 是一个非常规范化的选项，但如果您必须跨多种类型进行查询，则会回来并咬住您 - 如果添加新类型，每个
SELECT将有另一个联接。 维护噩梦。选项2（稀疏表）会有很多NULL值并占用额外的空间。 如果将来添加其他类型，表定义也需要更新。 没那么糟糕，但仍然很痛苦。
我在生产中使用选项 1（使用
xml类型而不是text）。 它允许我序列化从公共类型派生的任何类型，提取公共属性并将唯一属性保留在XmlProperties列中。 这可以在应用程序或数据库（例如存储过程）中完成。Option 3 is a very normalized option, but will come back and bite you if you have to query across multiple types - every
SELECTwill have another join if a new type is added. A maintenance nightmare.Option 2 (sparse table) will have a lot of NULL values and take up extra space. The table definition will also need updating if another type is added in the future. Not so bad but still painful.
I use Option 1 in production (using an
xmltype instead oftext). It allows me to serialize any type derived from my common type, extracting the common properties and leaving the unique ones in theXmlPropertiescolumn. This can be done in the application or in the database (e.g. a stored procedure).您的选择：
注释：
如果您想让数据库保持“关系型”，但又不害怕使用 ORM 工具，那么我会使用一个。 在这种情况下，您可以（几乎）按照您想要的方式存储数据，但只要正确映射它们，就可以正确处理它们。
请参阅：
如果您需要纯 SQL 解决方案，那么根据您的 RDBMS，我可能会使用 XML 列来存储特定于小工具类型的所有数据：您可以进行验证，并使用新属性轻松扩展。 然后，您可以将所有内容集中在一张表中，快速搜索所有常见属性，并且还可以轻松搜索一个小工具的类型属性
Your options:
Notes:
If you would like to keep your database 'relational', but are not afraid to use ORM tools, then I would use one. I which case you can store the data (almost) as you want, but have it properly handled as long as you map them correctly.
See:
If you need SQL-only solution, then depending on your RDBMS, I would probably use XML column to store all the data that is specific to the gadget type: you can have validation, extend easily with new attributes. Then you can have all in one table, search quickly on all common attributes, and also pretty easily search for one gadget' type attributes as well
如果所有类型的小工具都具有许多可以存储在一个表中的常见强制属性和几个可选属性，那么您最好使用第一种方法：这样您将使用最好的关系模式并通过 XML 简化您的生活。 并且不要忘记使用将 XML 列链接到它的 XML 模式集合：您将拥有完整的索引和 XQuery 功能。
如果小工具类型具有非常不同的描述，并且 5 个或更多不同的属性集中只有 1-3 个公共列，请使用第三种方法。
但对于 100 多种类型的小工具的情况，我会使用第一种方法：它具有良好的性能和易于支持和进一步开发的灵活性。
If all types of gadgets have many common mandatory properties that can be stored in one table and just several optional properties, you'd better use first approach: thus you'll use best of relational schema and ease your life with XML. And don't forget to use XML Schema collection linking XML column to it: you'll have full indexing and XQuery capabilities.
If gadget types has very different descriptions and only 1-3 common columns among 5 or more different set of properties, use 3rd approach.
But concerning the situation of 100+ types of gadgets I'd use 1st approach: it has flexibility supported with good performance and ease of support and further development.
根据“小工具”的不同程度，我不喜欢选项 2，因为会有很多空值浮动，如果您有一列对于一个小工具是必需的，但甚至不用于另一个小工具，这可能会变得很糟糕。
如果小工具的数量很少变化，我只会选择选项 3，因为每次都需要更改数据库。
未提及的选项是将小工具与子表一起存储，该子表保存小工具的唯一值。 但这需要大量的工作来返回小工具详细信息或多个数据库调用。
保留选项 1，除非我将使用 SQL 服务器 XML 类型而不是文本，然后您可以在存储过程中使用 XQuery。
Depending on how different the "Gadgets" are I wouldn't like option 2 there would be a lot of nulls floating around, which could get bad if you had a column which was mandatory for one gadget but not even used for another.
I would only go option 3 if the number of gadgets changes infrequently since it would require altering the database each time.
The unmentioned option is to store the Gadgets with a child table which holds the gadgets unique values. But this would require a fair amount of work to return gadgets details, or multiple Database calls.
Leaving option 1, except I would use SQL servers XML type instead of text, you can then use XQuery within your stored procedures.