我正在使用sql server 2005设计数据库
我们方的主要概念是从供应商导入xml供稿
不同的供应商可以有不同的数据表示
问题是我需要设计表来存储导入的信息
某些列已修复意味着所有供应商产品必须包含来自Feed，名称，代码，价格，状态等的类似数据
但某些产品有可选的详细信息，例如
一种产品可能具有其他可能的颜色属性。
将这类场景存储到数据库中的最佳方法是什么。
我应该为强制列和其他表创建一个表来保存可选列。
或者我应该首先列出所有列并将它们放入一个表中。 （可能有很多空值）
有数千种产品和数据库速度是非常必要的。我们将从不同的供应商那里做很多产品比较
我们的数据库将类似www.pricerunner.co.uk
我希望我能很好地解释这个概念
答案 0 :(得分：1)
取决于您希望如何访问它。
正如你所说，速度很重要 - 但是你要用那些额外的，可选的信息来做什么呢？你需要存放它们吗？假设你这样做，你需要多久访问一次？
基本上，如果你总是需要至少检查它们是否在那里，最好将它们放在一个表中。如果您还需要检查，也可以将其作为初始查询的一部分来完成。
另一方面，如果您通常可以在不费力地检查这些额外部件的情况下运行，并且只需要在特定要求时打扰，那么将它们放入不同的表中可能会更好。连接（或后续查找）将非常昂贵 - 比为空列提取空值要昂贵得多 - 但如果它非常罕见，从长远来看，在运行时执行中可能会花费更少。
还要记住存储和传输术语的权衡 - 存储大量空字段确实需要一些空间，并且发回大量空字段会占用网络带宽。
如果磁盘空间不是问题，但带宽是，请使应用程序设计合理，以尽量减少不必要的查找，然后使用严格的查询，您可以存储额外（可选）数据，但除非请求，否则不会将其传回。
所以，这完全取决于对你来说重要的事情。一旦你知道你最重要的设计问题是什么，你就会知道应该做出哪些妥协来解决这些问题而牺牲其他问题。平衡法。
答案 1 :(得分：1)
成千上万的产品（数千行）。这真的不多，所以你可以将可选数据规范化为几个单独的表，而不会对查询时间产生显着影响。
我想说把你的索引放在正确的位置，优化你的查询，确保你把文件组拆分得很好等等（只是通常常规的旧数据库的东西），你应该很好。