我对这两种结构很困惑。这两个表各有什么优缺点？
哪一个更好，为什么？
TABLE1
反模式？
在常见情况下，第二个表是反模式在数据库设计的背景下。而且，更重要的是，它有特定的名称：实体-属性-值（EAV）。在某些情况下，使用这种设计是合理的，但这种情况很少见——即使在这种情况下，也是可以避免的。
为什么 EAV 不好
数据完整性支持
尽管事实上这样的结构似乎更“灵活”或“先进”，但这种设计也有弱点。
-
无法设置强制属性。您不能强制某些属性，因为属性现在存储为一行 - 并且属性未设置的唯一标志 - 是表中不存在相应的行。 SQL 不允许您本地构建此类约束 - 因此，您必须在应用程序中检查这一点 - 是的，每次查询你的表
-
混合数据类型。您将无法使用 SQL 标准数据类型。因为您的值列必须是其中所有存储值的“超类型”。这意味着 - 通常您必须将所有数据存储为原始字符串。然后您将看到像处理字符串一样处理日期、每次转换数据类型、检查数据完整性等等是多么痛苦。
-
无法强制执行引用完整性。在正常情况下，您可以使用外键来限制您的值，这些值在父表中定义。但在这种情况下并非如此 - 这是因为引用完整性应用于表中的每一行，但不适用于行值。所以 - 你会失去这个优势 - 这是基本的之一关系数据库
-
无法设置属性名称。这意味着 - 您无法正确限制数据库级别的属性名称。例如，你会写
"customer_name"作为第一种情况下的属性名称 - 另一个开发人员会忘记这一点并使用"name_of_customer"。而且..没关系，数据库会通过这个测试，并且您将花费数小时来调试此案例。
行重建
此外，在常见情况下，行重建会很糟糕。例如，如果您有 5 个属性 - 那将是 5 个自表JOIN-s。对于乍一看如此简单的情况来说太糟糕了。所以我什至不想想象你将如何维持 20 个属性。
能有道理吗？
我的观点是——不。在 RDBMS 中总会有办法避免这种情况。这太糟糕了。如果打算使用 EAV，那么最好的选择可能是非关系型数据库。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
