【问题标题】:Adding unique key/index to table and its influence on existing records向表中添加唯一键/索引及其对现有记录的影响
【发布时间】:2013-12-11 10:07:38
【问题描述】:

到目前为止,我有一张没有唯一键的表运行良好。该表工作正常,但插入/更新/删除过程的代码变得有点不可读,因为识别表中正确条目的条件越来越长,所以我开始考虑添加一个具有唯一 ID 的新列.

已经回答了关于在 SO 上为表添加唯一标识的问题,但我想知道它是否会对当前存在的记录产生任何负面影响。表本身并不大,它从来没有超过几千个条目,但是它经常被使用和更新,并且要停止使用它并不容易。那么我应该注意什么可能会弄乱数据,或者我可以愉快地添加一个具有唯一标识的列并且一切都会正常工作吗?当前存在的存储过程是否存在任何问题,尤其是那些更改记录的存储过程?老实说,我什么都想不出来,但我宁愿确定,因为我在 SQL 和数据库方面的经验还很远。

向已经存在的表添加索引也是如此——我想这会涉及到一些变化,那么对记录有什么负面影响吗?

如果您需要我提到的过程示例,只需考虑带有不必要的长 where 子句的简单插入/删除/更新语句。没有与其他表的连接,单个过程中没有多个事务。

【问题讨论】:

  • 如果您还没有 一些 形式的数据密钥,那么添加一个新的密钥对缺乏数据质量毫无帮助 - 如果您目前没有强制执行键,没有什么可以阻止您在每列中拥有两行(或多行)包含完全相同的值。添加一个新列来唯一标识这些行并不能解决数据中仍然存在重复项这一事实。
  • @Damien_The_Unbeliever 你在质量方面是对的,但我是从 SP 的可读性角度考虑这种变化,以及使用数据库管理应用程序端的数据。目前,如果我想例如更新一条记录,我需要传递大量不必要的数据作为参数才能找到它。

标签: sql sql-server-2008-r2 indexing unique-key


【解决方案1】:

添加列或更改索引不会影响当前数据。

但代码可能会受到影响。

  1. SELECT * 现在将返回更多列。
  2. 列顺序可能会根据您添加列的位置而改变。
  3. 可能有人INSERT 没有列列表。现在将失败。
  4. 性能可能会稍微变差。如果您的应用程序依赖于非常严格的性能标准,这可能是个问题。我认为这不太可能。

我敢肯定还有其他的,但这些是我现在能想到的。

【讨论】:

  • 为什么添加唯一键可能会成为性能问题?我认为如果大多数长 where 子句从插入/更新等中消失,添加 ID 后实际上可能会更快。
  • 如果您修改查询以利用它们,这可能会有所帮助,是的。你可能会实现一些收益。我的评论是针对您只添加列而不进行其他任何更改的情况。我以为您关心现有代码在更改下的行为方式。
猜你喜欢
  • 2019-10-16
  • 1970-01-01
  • 1970-01-01
  • 2018-02-20
  • 1970-01-01
  • 2014-08-30
  • 2013-02-21
  • 1970-01-01
相关资源
最近更新 更多