mysql - "Merging"多个数据库表

Question

关闭。这个问题需要更多 focused 。它目前不接受答案。












想改进这个问题？更新问题，使其仅关注一个问题 editing this post 。

7年前关闭。




Improve this question




我在这里阅读了关于将多个数据库合并为一个的多个问题，但是它们主要都处理统一的模式/表。如果我重复一个问题，我很抱歉。

我有各种相似但不相同的数据库表。例如，假设有十个数据库有十个“用户”表。所有都包含一个 userid(我们将使用它作为引用)。大多数包含 username 和 email 列。有些将包含其他列，例如 skype 、 msn 、 phone 等，这些列仅存在于其他几个表中，或者没有其他表。

我想将这些内容合并到一个数据库中，前提是，在 future ，其他数据库也包含唯一列的可能性也需要合并到新数据库中。

我一直在查看 EAV 表，并且正在考虑类似于(继续上面的示例)主用户表，该表具有新分配的用户 ID(id)，起源于某种类型的数据库引用(database_id)，和原始用户 ID ( native_user_id )。然后，我将有一个单独的属性表，其中包含主键 (id)、实体键 (user_id)、属性 (attribute) 列和值 (value) 列。

手头的问题是，我读过的几乎所有内容都建议反对 EAV 表，同时暗示有更好的方法来解决这个问题。但是，我实际上还没有找到任何涵盖这种方法的 Material 。

所以，我的问题:

EAV 表真的那么糟糕吗？

如果我走 EAV 表路线，我应该提前计划哪些实际的重大失败(个人经验的任何例子都会膨胀)？

除了 EAV 表(同时适应 future 的属性而无需繁琐的 ALTER TABLE 命令)，还有哪些替代方案可以处理这种类型的场景？

Answer 1

我在一个项目中使用 EAV 来解决与您类似的需求:在困惑的现实世界中缺乏通用数据模型。

就我而言，EAV 允许随着公司通过收购而增长而进行增量更改，这反过来又导致数据模型的持续扩展、改进或泛化。该项目最终失败了，因为管理层撤回了对它的支持。

我了解到，EAV 向管理层和用户呈现出不必要的复杂性，除非您努力创建简洁的 View 以隐藏复杂性，同时保持数据的完整性。我还了解到 EAV 要求以有意义的方式填写“缺失的答案”。仅仅说数据库 X 中未提出的问题的每个答案都是“NULL”是不够的。有时这不是正确的答案。 “NULL”成为“我不知道；该属性在此数据库中不存在，因此没有人决定该值应该是什么”的同义词。