Sql 将代理id键添加到遗留数据库中的无键表中；它会如何影响与数据库通信的业务应用程序？

我这样问是因为我们一直在处理遗留数据库，如果您试图在没有主键的表上放置ORM，可能会出现问题。在这个论坛上，许多回答这个问题的人都说（在我看来，他们相当漠不关心），只需在表中添加一个主键。没什么大不了的

---

现在我要问的是，若您突然将主键添加到现有数据库中的表中，您能想象到什么可能的负面影响，尤其是对客户端应用程序？如果问题过于宽泛，这几乎已经回答了我的问题。

在开始之前，请确保没有其他机制来实施唯一性。例如，

notnull unique

声明在行为上等同于

主键

声明。可能有触发因素；可能存在需要数据库更新才能通过存储过程的权限；今天早上我可能还没有想到其他机制

您似乎在讨论添加一个自动递增整数的列，并将其声明为主键

假设当前确实没有主键，并且没有其他与主键等价的东西，主要问题涉及隐式依赖于列顺序或列数的应用程序代码

例如，这是一个有效的SQL语句。您可能会在应用程序代码中发现类似的内容

select *
from your_table
order by 1 desc;

该语句将按第一列中的值降序排列结果集

如果向该表中添加一列，并将该列定位为表定义中的第一列，则该SQL语句将开始以与其他客户端所期望的不同的顺序返回数据

一些平台不允许

altertable

语句更改列的顺序；新列仅位于表定义的末尾。但即使在这些平台上，DBA也可以转储数据，首先用新列重写

createtable

语句，然后重新加载数据

这种问题——更改表中的列数——可能会中断某些数据导入和导出

插入没有列名的语句，如

Insert-into-foo-values（…）

可能会失败

类似的语句也可能出现在触发器中，但这更像是数据库代码的问题，而不是应用程序代码的问题

存在一些性能问题的可能性。使用新列作为聚集索引（某些平台上的选项）将更改行的物理顺序。这肯定会改变性能，但我无法预测这是否一定是件坏事。表会更宽，但不会更宽，这意味着磁盘上一页上可以容纳的行会稍微少一些

弹性解决方案

• 更改现有表的名称。（这很简单，但可能并不容易。）
• 创建与原始表具有相同结构和名称的可更新视图
• 更改原始表的结构

所有使用原始表名称的应用程序代码现在都将使用可更新视图的名称。由于视图的结构和行为与原始表相同，因此所有应用程序代码都应该继续工作。（如果应用程序代码需要知道它是处理表还是处理视图，我会感到惊讶，但这是一个可能的问题。）

注意事项

在任何情况下，您都不应该首先在生产中进行此更改。您应该首先在本地进行更改，然后在您的测试环境中进行更改，最后——当您用尽了我们的集体想象力之后——进行生产

---

一次一点地投入生产。添加列，然后等待一段时间。填充列，然后等待一段时间。重复操作，直到完成。

这可能会以超出您想象的更多方式对当前业务应用程序产生负面影响。没有大量的细节，我不确定这里的任何人是否能帮上大忙。这就是测试服务存在的原因。在测试数据库中添加pks，然后查看应用程序是如何中断的。修复应用程序，而不是删除PKs，因为它们很方便，正如您已经注意到的。我认为OP并不是要求我们想象一个新专栏会以各种方式影响愚蠢的应用程序代码。这一变化实际上与添加列没有什么不同。这里的主要关键约束是转移注意力；它由dbms自动维护，这也保证了唯一性，并且不会影响任何现有或未来行的唯一性（因为当前没有键）。引入一个新列（在表的末尾）几乎是对现有表进行的最安全的结构更改。因此，简而言之，我不认为这个问题太广泛。我要补充的是，如果表中有大量记录，添加键的过程可能会很长。这在prod上可能是一个真正的问题。您还将在使用select*的任何地方显示此键，这可能是不需要的。可能需要重新生成视图以包含该列（在SQL Server中，甚至在使用select*的视图中）。如果有insert语句，如果未指定列名，它们可能会中断。如果调用字段ID，您可能会遇到重复列名的问题，从而导致报告中出现问题。某些触发器、数据导入或数据导出可能会中断。我合并了您的注释，只跳过了与数据库代码有关而与应用程序代码无关的部分。谢谢