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