SQL表的体系结构

Question

我想知道在sql中使用两列（一列包含外键和一列包含随机数据）创建多个表更有用和实用（DB的大小）或合并它并创建一个包含多列的表。我问这个是因为在我的场景中，一个持有主键的产品可能只有一列有足够/适用的数据，而其他列则为空。

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

Answer 1

多表方法更“正常”（在数据库术语中），因为它避免了通常存储NULL的列。这也是编程术语中的一个难点，因为你必须加入一堆表来恢复原始实体。

我建议采用中间方式。重量似乎是大多数产品的属性，如果不是全部（事实上，即使很小的环也有重量，你可能想知道它用于运输目的），所以我将其保留在Products表中。但是，页面数量仅适用于书籍，大量其他未提及的属性（作者，ISBN等）也是如此。在这个例子中，我使用Products表和Books表。 books表将以类似于面向对象程序中的类继承的方式扩展 Products表。

所有图书专用属性都会进入图书表格，您只能加入产品和图书以获得图书的完整描述。

Answer 2

我认为这一切都取决于表格的使用方式。也许你的例子过于简单化，但在我看来，第一个选项应该足够好。

你真的使用第二个例子，如果你要用第一个表做极其CPU密集的东西，只需要有关产品的更多信息时需要第二个和第三个表。

如果您在查询表时大多数时候需要第二个和第三个表中的信息，那么每次都没有理由加入，您应该将其保存在一个表中。

Answer 3

我会建议示例a，如果有一组已定义的产品属性，并且示例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而不是pk。

Answer 4

这取决于您在PRODUCTS表上预期的行数。我想说在这种情况下将表格标准化为3N是没有意义的，因为产品名称，重量和no_of_pages都描述了产品。如果您有重复数据，例如制造商，那么在此时规范化表格会更有意义。

Answer 5

在不知道背景（数据模型）的情况下，无法确定哪个变体更“正确”。在某些情况下两者都很好。

Answer 6

你想要三张桌子，完全停下来。这是最好的，因为没有机会让手表清理页面（没有双关语）和一些没有书籍的书籍。如果您正常化，则服务器适合您。如果你不这样做，那你就做了工作，而不是那么做。由你决定。

  

我问这个是因为在我的情况下，一个持有主键的产品可能只有一列有足够/适用的数据，而其他列则为空。

可以为空的列总是如此。以下是规则：可空列与键具有可选关系。可以为空的列始终是，并且通常应该是在一个单独的表中，它可以是非空的。