Question

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

我有各种各样的数据库表，它们都相似但不完全相同。例如，想象十个具有十个“用户”表的数据库。全部包含userid（我们将使用此作为参考）。大多数包含username和email列。有些列会包含其他列，例如skype，msn，phone等，这些列仅存在于少数其他表中，或者不存在于其他表中。

我希望将此内容合并到一个数据库中，前提条件是，还需要将包含唯一列的其他数据库合并到新数据库中。

我一直在研究EAV Tables，并且正在考虑一些事情（继续上面的例子）一个主用户表，它有一个新分配的用户ID（id），原始数据库参考某种类型（database_id）和原始用户ID（native_user_id）。然后，我将有一个单独的属性表，其中包含主键（id），实体键（user_id），属性（attribute）列和值（{{1 }}）列。

手头的问题是，我读过的几乎所有内容都建议不要使用EAV表，同时暗示有更好的方法可以解决这个问题。但是，我实际上并没有找到任何涵盖这种方法的材料。

所以，我的问题：

EAV表真的坏吗？
如果我选择EAV表路线，那么我应该提前规划哪些实际的重大失误（任何个人经验的例子都会膨胀）？
除了EAV表之外，还有哪些替代方案可以处理这种类型的场景（同时在没有繁琐的ALTER TABLE命令的情况下适应未来的属性）？

Answer 1

我在项目中使用EAV来解决与您类似的要求：在凌乱的现实世界中缺乏通用数据模型。

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

我了解到EAV向管理层和用户展示自己是不必要的复杂，除非你做的工作是创建简洁的视图来隐藏复杂性，同时保持数据的完整性。我还了解到，EAV强加了一个要求，以填补＆＃34;缺失的答案＆＃34;以一种有意义的方式。仅仅表示对数据库X中没有提出的问题的每个答案都是＆＃34; NULL＆＃34;。有时这不是正确的答案。＆＃34; NULL＆＃34;成为＆＃34的同义词;我不知道;该数据库中没有该属性，因此没有人决定该值应该是什么＆＃34;。

Answer 2

这是一个相当广泛的问题，嗯？

如果您的表已经在SQL中，我建议您尝试使用这种UNION ALL查询。

 SELECT 'one' AS dbid, 
        id AS id, 
        first AS first_name, 
        last AS last_name 
   FROM first_table
 UNION ALL
 SELECT 'two' AS dbid, 
        member_id AS id, 
        fname AS first_name, 
        lname AS last_name 
   FROM members

等等。我们的想法是使用UNION ALL查询来尝试将您的各种信息源强制转换为单个结果集，并找出来自这些不同来源的哪些值在某种程度上是一致的。如果大部分数据符合要求 - 也就是说，您只需将其移动到新表中的相应列中，您就可以避免EAV存储的最大陷阱。

完成后，您可以使用EAV样式存储来获取剩余信息。

我希望这有助于您稍微规划一下此迁移。

＆＃34;合并＆＃34;多个数据库表

2 个答案: