我们有一个过时的数据库,其中包含大量个人以及他们已经完成的许多成就。从历史上来看,几乎没有做过阻止重复的单个数据的事情,因此我们最终陷入了数据非常脏的情况。可以在here上找到其简化版本。
现在,我们正在重新设计架构和用户界面。我们将为用户提供将其个人合并在一起的工具。在所提供的示例中,Dave和David显然是同一个人,总共取得了4项成就。
考虑到用户会犯错误,并且涉及的表比示例中的要多,我正在寻找一种模式设计,该模式设计可以简化数据的合并,尤其是在(不可避免的)用户(当!)时取消数据的合并。犯了一个错误。
某种形式的链接列表似乎是一种解决方案,但对于该用例而言并非完全有效。还有其他概念可能适合这种情况吗?任何合适的特定设计模式?
编辑:由于今天的SQLFiddle非常脆弱,这是sqlfiddle上的create/insert/select sql:
CREATE TABLE individual
(`individual_id` int, `forename` varchar(50), `surname` varchar(50))
;
CREATE TABLE achievement
(`achievement_id` int, `name` varchar(50), `description` varchar(50))
;
CREATE TABLE individual_achievement
(`individual_id` int,`achievement_id` int)
;
INSERT INTO individual
(`individual_id`, `forename`, `surname`)
VALUES
(1, 'Dave', 'Deane'),
(2, 'David', 'Deane')
;
INSERT INTO achievement
(`achievement_id`, `name`, `description`)
VALUES
(1, 'unit_1', 'Unit 1'),
(2, 'unit_2', 'Unit 2'),
(3, 'unit_3', 'Unit 3'),
(4, 'unit_4', 'Unit 4')
;
INSERT INTO individual_achievement
(`individual_id`,`achievement_id`)
VALUES
(1, 1),
(1, 3),
(2, 2),
(2, 4)
;
select * from individual i
join individual_achievement ai using (individual_id)
join achievement a using (achievement_id)
编辑2:刚刚找到了这个very similar question,希望在4年后也可以找到其他解决方案。
最佳答案
这是您可以使用的一种策略。
首先,创建一个新表,现在将其称为“Individual_v2”,其列与原始表Individual完全相同。 (理想情况下,您最终将用此表替换“个人”;实际上,人们可能仍会在“个人”中输入数据,并且您必须通过将数据移动或合并到“Individual_v2”中来“清理”数据。)使用指向“成就”的链接配置此表。 (目前,我假设成就是干净的。)
然后,创建一个“映射”表,如下所示:
IndividualMapping
OldIndividual_Id
NewIndividual_Id
CreatedAt
CreatedBy
ApprovedAt -- Nullable!
ApprovedBy -- Nullable!
“已创建”列用于确定何时以及由谁(或什么)创建映射。
“已批准”列用于确定数据是否已迁移到新表。
对于每个“旧”项目,您都可以确定它在"new"表中的映射位置;如果它没有映射到现有项目,则在新表中为其创建一个。
然后,在映射表中添加一个条目。如果创建了新项目,则将其标记为已批准;否则,将其标记为已批准。如果置信度很高,则将其标记为已批准;否则,将其保留为“未批准”并等待审核。在适当的时候,审阅者会仔细检查并批准映射,将映射更改为其他现有的新项目,或者创建另一个新项目并映射到该项目。
完成后,将针对新表完成“实际”工作。旧表和映射表可用于标识新数据的来源,并在必要时撤消/更改映射。
这里有很多 Unresolved 实现和支持问题,总的来说,这似乎很尴尬。从长远来看,一旦解决了重复数据的问题,您可以删除旧的(和映射)表,但是在那之前,您将拥有一个繁琐的系统。
附录
我在这里只是在讨论一些事情,而没有进行详尽的分析。我认为您正在描述的系统将是繁琐的工作,并且在概念上非常复杂,即使表格相对简单,并且最终细节不在SO问题的范围之内。同样,很大程度上取决于系统及其重新设计的总体目标和目的。我将在这里做一些假设:
以这种方式完成后,系统将按以下方式工作:
您可能需要一些额外的日志记录表来跟踪诸如“通过xx/xx/xxxx输入的所有数据均有效,此后输入的数据必须进行审核”之类的内容。我敢肯定还有其他问题和微妙之处会浮现出来,它们总是会…
关于design-patterns - 合并数据的数据库架构设计模式,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/31876595/