SQL表的体系结构

我想知道在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

---

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

如果要使用第一个表执行CPU密集型的工作，并且只需要在需要更多产品信息时使用第二个和第三个表，那么可以使用第二个示例

---

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

我建议使用示例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。

多表方法更“正常”（在数据库术语中）因为它避免了通常存储空值的列。这也是编程术语中的一个难题，因为您必须连接一组表才能恢复原始实体

我建议采用中间的方法。重量似乎是大多数产品的属性，如果不是全部的话（事实上，一个戒指的重量即使很小，你可能想知道它的运输目的），所以我会把它放在产品表中。但页数只适用于一本书，还有许多其他未提及的属性（作者、ISBN等）.在本例中，我将使用Products表和Books表。Books表将以类似于面向对象程序中的类继承的方式扩展Products表

---

所有特定于书籍的属性都进入Books表，您只需将Products和Books连接起来即可获得一本书的完整描述。

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

如果不知道背景（数据模型），就无法判断哪个变体更“正确”。在某些情况下，两者都可以。

您需要三张桌子，句号。这是最好的，因为手表不可能有书页（没有双关语）而有些书没有。如果您正常化，服务器会为您工作。如果您不正常化，则由您来代替，只是不太好。取决于您

我这样问是因为在我的场景中，一个拥有主键的产品可能只有一列有足够/适用的数据，而其他列则为空

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

---

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

这是实体值布局，请记住，如果没有EVL.yesp，则不能拼写邪恶，但如果属性数为not fixed，那么这是最好的布局。正如我提到的，如果一开始就知道属性的数量，那么最好使用示例a。谢谢Larry，但是你不认为有Books表、Rings表等会很复杂吗？例如，扩展某个产品的所有可用信息。例如，如果（随着时间的推移）会怎么样某些信息适用于书籍和戒指，但不适用于手表。您应该将这些信息放在products表中，还是在Books和Watches表中都有重复的列？这取决于您的数据库中可能合理出现的产品类别数。我会尝试设计系统，以使大多数类别适合产品没有扩展程序的表。对于多个类别中的常见信息，我必须判断它是否属于Products表中的1）值，2）在两个扩展程序表中重复，或3）在Products表和其他两个扩展程序表之间的中间扩展程序中重复。因此，这就引出了另一个问题-表是基于产品还是基于属性或属性集（按主题分组）创建？基于产品还是产品类别。您的表应该反映数据模型中的实际实体。这是真的，但是数据库的大小呢？表是否倾向于扩展数据库的大小而不是列？