2015-06-16 57 views
0

我正在更新最初设计不佳的表。该表目前有一个主键是供应商的名称。这可以作为许多其他表格的外键。这导致了供应商名称初始输入错误或需要修复的拼写错误。由于这是关系的外键,所以这比它的价值更复杂。在Oracle中更改主键

当前架构: VENDOR_NAME(PK)Vendor_contact评论

需要的模式: ID(PK)VENDOR_NAME Vendor_contact评论

我想要更新的主键是自动生成的,数字键。供应商名称字段需要保留,但不再是关键。我还需要更新其他表和联接表上外键的值。

最好的办法是在我的供应商表上创建一个新的数字标识列,crosswalk将供应商名称标识为id并添加一个新的外键,并将新的id作为外键,放弃供应商的外键这些表上的名称(根据this post),然后以某种方式将该ID标记为主键,并取消标记供应商名称?

还是有更简化的方式做到这一点,这是不是很破碎?

重要的是要注意,只有5个用户可以访问这个表格,所以我可以在这些更新完成的一段时间内轻松关闭它们 - 这不是问题。

我正在使用SQLDeveloper和Python/Django。

+0

哪个版本的数据库? – APC

+0

我们最近升级到12C。 – rockman

回答

0

您遇到的最大问题是在从属表中引用VENDOR_NAME的所有应用程序代码。不只是使用它加入父表,还依靠它来显示名称而不加入VENDOR。

因此,虽然拥有一个作为外键的自然键是PITN,但改变这种情况可能会产生大量工作,并带来边际整体收益。在开始之前一定要获得所有利益相关者的支持。

我想接近它的方式是这样的:

  1. 做一个真正彻底的影响分析
  2. 确保您有完整的回归测试都依赖于卖方的数据
  3. 创建VENDOR_ID的功能对供应商提供的唯一键
  4. 添加VENDOR_ID所有从属表
  5. 创建引用的所有从属表二外VENDOR_ID
  6. 确保每当VENDOR_NAME出现VENDOR_ID都会填充。

最后一点可以通过在相关表上修改插入和更新语句或者使用触发器来解决。您采取的方法将决定您的应用程序设计以及涉及的表格数量。如果可以的话,显然你想避免所有这些触发器的性能打击。

在这一点上,你有一个基础设施,将支持新的主键,但仍然使用旧的主键。你为什么想做这个?因为您可以像这样进入Production,而无需更改应用程序代码。它使您可以选择在更广泛的时间范围内移动应用程序代码以使用VENDOR_ID。显然,如果开发人员一直热衷于编码SELECT * FROM,您将遇到需要立即解决的问题。

修复所有代码后,您可以从所有从属表中删除VENDOR_NAME,并将VENDOR_NAME切换为唯一键并将VENDOR_ID切换到主表上的主键。

如果您使用11g,则应该查看基于版本的重新定义。它旨在使这种练习变得非常简单。 Find out more

0

我会做这种方式:

  • 创建新的序列
  • 创建临时表作为选择your_sequence.nextval,VENDOR_NAME,vendor_contact,从供应商的意见。
  • 原始表重命名为类似vendor_old
  • 添加主键和其他约束到新表
  • 新表重命名为旧名称

测试是必不可少的,你必须保证没有除非你完成这个工作,否则一个人正在处理数据库。