mysql - 两种表结构的区别

Question

我对这两个结构很困惑。这两个表的优点和缺点是什么？哪个更好，为什么？

表 1

id,         name,       age,        birthdate,      address
somedata1   somedata1   somedata1   somedata1       somedata1
somedata2   somedata2   somedata2   somedata2       somedata2
somedata3   somedata3   somedata3   somedata3       somedata3  

表 2

id,         col_name,   col_value

somedata    name        somedata
somedata    age         somedata
somedata    birthdate   somedata
somedata    address     somedata

somedata2   name        somedata2
somedata2   age         somedata2
somedata2   birthdate   somedata2
somedata2   address     somedata2

somedata3   name        somedata3
somedata3   age         somedata3
somedata3   birthdate   somedata3
somedata3   address     somedata3

Answer 1

反模式？

在通常情况下，第二个表在数据库设计上下文中是反模式。而且，更重要的是，它具有特定名称:Entity-Attribute-Value (EAV)。在某些情况下，使用此设计是合理的，但这种情况很少见 - 即使在这种情况下也可以避免。

为什么 EAV 不好

数据完整性支持

尽管这样的结构看起来更“灵活”或“先进”，但这种设计也有弱点。

• 无法设置强制属性。您不能强制某些属性，因为属性现在存储为一行 - 并且未设置属性的唯一标志 - 是表中不存在相应的行。 SQL 不允许您在本地构建此类约束 - 因此，您必须在应用程序中进行检查 - 是的，每次都查询您的表
• 混合数据类型。您将无法使用 SQL 标准数据类型。因为您的值列必须是其中所有存储值的“父类(super class)型”。这意味着 - 您通常必须将所有数据存储为原始字符串。然后你会发现处理日期和处理字符串一样痛苦，每次都转换数据类型，检查数据完整性等等。
• 无法实现引用完整性。在正常情况下，您可以使用外键来限制您的值，这些值在父表中定义。但在这种情况下不是 - 这是因为引用完整性应用于表中的每一行，而不是行值。所以 - 你会失去这个优势 - 它是 关系数据库中的一个基本
• 无法设置属性名称。这意味着 - 您无法在数据库级别正确限制属性名称。例如，在第一种情况下，您将编写 "customer_name" 作为属性名称 - 而另一个开发人员会忘记这一点并使用 "name_of_customer"。并且..没关系，DB 会通过它，您将花费数小时来调试此案例。

行重建

此外，行重建在通常情况下会很糟糕。例如，如果您有 5 个属性 - 那将是 5 个自表 JOIN-s。对于如此简单的 - 乍一看 - 案例来说太糟糕了。所以我什至不想想象您将如何维护 20 个属性。

是否合理？

我的观点是——不。在 RDBMS 中，总有办法避免这种情况。这太糟糕了。如果打算使用 EAV，那么最好的选择可能是非关系数据库。