3

I know full well this should never happen. Ever. However, I started working at a company recently that hasn't had the greatest database design or input validation and this situation has come up.

There is a table which we'll call 'jobs'*. Jobs has a primary key, 'ID'. The job with the ID of 1 has loads of data associated with it; However, stupidly someone has duplicated that job as id 2 (this has happened around ~500 times so far). All of the information for both needs to be merged as id 1 (or 2, it doesn't matter).

The columns ARE linked by Foreign Key with UPDATE: CASCADE and DELETE: RESTRICT. They are not all called jobs_id.

Is my only (seemingly sensible) option here to:

  1. Change id 1 to something I can guarantee is not used (2,147,483,647)
  2. Temporarily remove the Foreign Key DELETE: RESTRICT
  3. Delete the entry with id 1
  4. Update id 2 to 2,147,483,647 (to link it with all the other entries)
  5. Change id 2,147,483,647 to id 2
  6. Reinstate DELETE: RESTRICT

As none of the code actually performs a delete (the restriction is there just as a fail-safe (someone editing direct in DB)), and the update: cascade is left in, data shouldn't get out of sync. This does seem messy though.

This will be wrapped in a transaction.

I could write something to iterate through each table (~180) and each column to find certain names / conditions, then update from 1 to 2, but that would need maintenance when a new table / column came along.

As this has happened a lot, and I don't see a re-write to prevent it happening any time soon, the 'solution' (sticking plaster) needs to be semi-automatic.

  • not the table's real name. His (or her) identity has been disguised so he (or she) doesn't get bullied.

Appreciate any input.

4

1 回答 1

0

假设您知道如何识别重复记录，为什么不创建具有相同结构的新表（可能没有 FK），然后在将值复制到新表时遍历原始表。当您遇到重复时，在写入新表时修复该值。然后删除原始文件并将临时重命名为原始文件。

这将清理表格，但如果进程仍在制作重复条目，您可以使用唯一键来限制未来的损坏。

于 2012-12-18T00:03:48.943 回答