我想知道的是它更有用，更实用（DB的大小）来创建SQL多个表中有两列或合并，并创建一个表（包含外键和含有随机数据，一列一列）包含多列。我这样问是因为在我的方案中，一个持有主键的产品可能只有一个列有足够的/适用的数据，而其他列将是空的。架构SQL表
example a. one table
productID productname weight no_of_pages
1 book 130 500
2 watch 50 null
3 ring null null
example b. three tables
productID productname
1 book
2 watch
3 ring
productID weight
1 130
2 50
productID no_of_pages
1 500
多表的做法是更“正常”（在数据库术语），因为它避免了常见的存储NULL的列。这在编程方面也是一种痛苦，因为你必须加入一堆表格才能恢复原始实体。
我建议采取一条中间道路。重量似乎是大部分产品的属性，如果不是所有的（事实上，一个环的重量，即使小，你可能会想知道它是用于运输目的），那么我会离开，在产品表。但是，页数只适用于一本书，其他一些未提及的属性（作者，ISBN等）也适用。在这个例子中，我使用了一个Products表和一个Books表。在面向对象的程序类似于类继承的方式将书表将延长产品表。
所有特定书籍的属性进入Books表，与您携手唯品和书籍，以得到一本书的完整描述。
我认为这一切都取决于如何使用表。也许你的例子太过简单化了，但在我看来，第一种选择应该足够好。
你真的要使用第二个例子，如果你打算做非常CPU密集型的东西的第一个表，并且需要有关产品的更多信息时，只需要在第二和第三个表。
如果你将需要第二和第三表中您查询表次数最多的信息，那么我们没有理由每次参加过和你应该保持在一个表中。
我建议例如，万一有一组定义的产品属性，和c，如果你需要可变数量的属性（新属性滚滚而来飘飞）的一个例子 -
例如，c
productID productName
1 book
2 watch
3 ring
attrID productID attrType attrValue
1 1 weight 130
2 1 no_of_pages 500
3 2 weight 50
已在实施例b所示的表结构不被标准化 - 会有在第二和第三表所需不同的ID的列中，由于的productId将是一个FK，而不是一个峰
这是实体值布局，并记住你不能没有EVL法术邪恶。 – 2010-11-11 19:22:07
是的，但如果属性的数量不固定，那么这是最好的布局。正如我所提到的，如果属性的数量在开始时是已知的，则示例a是优选的。 – 2010-11-12 15:46:56
这取决于你有多少行期待您的产品表。我会说，它是没有意义正常化你的表到3N在这种情况下，因为产品名称，重量和no_of_pages各自描述的产品。如果您重复制造商等数据，那么在此时对表格进行规范化会更有意义。
不知道背景（数据模型），没有办法分辨哪个变种更“正确”。在某些情况下都很好。
这是真的，但是数据库的大小呢？表格倾向于扩大数据库的大小而不是列？ – mko 2010-11-11 19:37:02
你想三个表，句号。这是最好的，因为手表没有机会用纸页（没有双关语）和一些没有的书。如果你规范化，服务器为你工作。如果你不这样做，那么你就做这项工作，而不是那么做。由你决定。
我在问这是因为在我的方案中，一个产品持有主键可能只有一个列有足够的/适用的数据，而其他列将是空的。
这一直是空列也是如此。这里的规则：一个空的列有关键的可选关系。可以为空的列始终可以，通常应该放在一个单独的表中，它可以是非空的。
感谢拉里，但是你不觉得这将是复杂，有书表，戒指表等即。扩展某个产品的所有可用信息。例如，如果（随着时间的推移）某些信息因为可用于书籍和戒指而不适用于手表。你应该将这些信息放在产品表中还是在书籍和手表表格中有重复的列？ – mko 2010-11-11 19:28:37
这取决于您的数据库中可能合理发生的产品类别数量。我会尝试设计系统，以便在没有扩展器的情况下将_most_类别放入Products表中。对于多个类别的公共信息，我不得不使在产品表的判断值是否它属于1），2）重复两个增量的表或3）在产品表和其他两个之间的中间扩扩展表。 – 2010-11-11 19:33:38
所以这使我们的另一个问题 - 基于产品或基于属性或属性集（按主题分类）创建宜表。 – mko 2010-11-11 19:40:39