使用旧系统，许多表没有主键。 DB是MSSQL server 2008，db在几年前从foxpro迁移过来。
我想在没有它们的情况下将PK添加到表中，但是我会反击“因为它可能会破坏某些东西。”
尽我所能，我可以想到没有可能发生的现实场景。推回的人不能给我一个例子，他们只是想要“安全”。安全是导致不作为导致不必要的工作。无论如何，任何人都可以给我一个现实的场景，这可能会导致现有的.net代码出现问题吗？或者确认它不会破坏现有代码。
添加PK的原因是能够使用Entity Framework生成DAL。某些表存在问题，其中没有合适的PK。也许我应该问一下在现有表中添加新列的风险是什么？但是，对于其中一些表格，这种做法非常频繁，没有任何问题。
答案 0 :(得分：1)
没有保证。
我可以想象破坏的一个领域是SELECT *语句和代码，它们需要按特定顺序返回一定数量的列。添加一个或多个PK列可能会破坏它。
但是为了PK而添加PK并没有真正增加价值。 PK帮助CRUD（特别是UD部分:)）所以你必须改变代码才能利用它。
答案 1 :(得分：1)
如果您选择自动增加任何这些新创建的主键，则可能会遇到Identity Insert问题。
答案 2 :(得分：1)
尽管我讨厌帮助您使用Entity Framework，但我必须说，如果您检查了列以确保没有空值且没有重复项，那么您可以将其声明为PK。添加新列风险更大但是将现有列作为PK应该是相当简单的，坦率地说，如果结果有任何中断（即，当你不想要任何东西时它试图插入副本），那么这很好，因为如果如果某些东西试图使它不唯一，那么这个列应该是唯一的。
贵公司需要的是清楚地了解如何成功重构数据库，这样他们就不会觉得这是不可能的。我强烈建议你阅读，Reforsing Databases by Ambler和Sadalage。 （http://www.amazon.com/Refactoring-Databases-Evolutionary-Addison-Wesley-Signature-ebook/dp/B001QAP36E/ref=sr_1_1?s=digital-text&ie=UTF8&qid=1385070572&sr=1-1&keywords=refactoring+databases）。有一些方法可以降低反应数据库的风险。
答案 3 :(得分：0)
使用较低的环境并进行所需的主键更改并完全测试应用程序。我能想到的唯一一个与@ n8wrl的回答相同。
如果你的遗留应用程序使用它所提取的字段的名称，你应该没问题。如果您的应用使用说：myDataReader(0).toString()
如果你可以确保添加的字段是表格中的最后一个字段，那么我想即使这样也可以减轻。我知道你的感受，但你的团队正在使用“S ** T Happens”的论点。它很有可能弄乱主键。您还需要问自己，公司中的任何其他应用程序是否依赖此数据库。我会说“要非常小心，并采取备份”。从理论上讲，我无法看出为何无法完成任何理由。