Microsoft Access是否使用PK字段进行任何操作？

Question

好吧，这听起来很奇怪，但我继承了一个应用程序，它是一个带有SQL Server后端的Access前端。我正在为它编写一个新的前端，但是......我们需要继续使用访问前端一段时间，即使我们部署了新的前端，原因是我不会介入。所以现有的Access应用程序和我的新应用程序都需要能够访问和使用这些数据。

问题是数据库设计是一场噩梦。例如，一些简单的父子表关系就像4和5部分组合主键。

我真的很想删除这些PK并用唯一的约束或其他替换它们，并向这些表中添加一个名为ID的新列，该ID只是一个标识。

如果我将这些表上的PK和FK更改为更多可管理的字段，Access应用程序是否有问题？我的意思是，访问是否使用表格中的元数据（PK和FK信息）以这种方式破坏应用程序来更改这些数据？

Answer 1

它不应该“破坏”应用程序，但您将不得不刷新链接表。 Access确实使用PK信息来确保它可以对行执行更新操作。它必须有一个唯一的密钥才能找到更新的行。如果没有定义PK，当你链接一个表时，它会要求你识别一个PK。

如果您添加代理身份PK，您应该没问题 - 只要表格刷新。

Answer 2

这里的问题是连接到数据库服务器将继续运行，并且Access本身作为客户端将能够运行和更新记录。因此，Access不关心你是否将一堆列设置为主键，并将其替换为自动编号ID或将单列作为主键。

然而，对上述情况说“是”意味着什么都没有，并且在这里完全没有任何帮助，因为这不是正确的问题。这里的问题是程序逻辑本身是否依靠这些功能来首先设置这些主键？

例如，我们可能会预订房间。所以主键可能是日期和房间号码。所以现在所有的程序逻辑都必须在日期和房间号输入系统之后才会尝试写出记录。如果返回的错误消息是主键违规，则程序逻辑可能会弹出消息，并表示您无法预订当天的该房间（号码）。

如果您将该应用程序更改为使用某个ID列的主键运行，那么当程序逻辑尝试写出该记录时，不会再有主键违例的错误消息。添加一些约束或索引，说明两个列必须是唯一的将不会解决这个问题，因为您必须在应用程序中查找代码正在查找主键违规的位置，现在修改该代码以使其查找某种类型的索引错误或某种类型的约束违规错误。

顺便说一句，这个问题并不是特别针对ms访问，但实际上您使用的任何软件和应用程序编程环境都会受到上述问题的影响。唯一的方法是找出所有代码行和应用程序的所有片断和部分，以查看它们中的任何一个是否依赖于主键结构具有的任何功能存在于应用程序中。你可能是幸运的，也许任何表错误都足够了，但你不知道，直到你看到实际的代码本身。

除非通过查看数据更新地点的所有代码，否则根本无法确定此问题。

所以，虽然大多数事情应该工作，并且像表单仍然会编辑数据。换句话说，Access不会太在意，但代码和应用程​​序本身肯定会非常关心这个问题。

我的意思是，即使在SQL服务器端，可能有一些存储过程和触发器的工作，这一事实。如果修改构成主键的内容，那么现有存储过程以及基于当前设计假设的许多关系如何？

现有的SQL存储过程甚至sql触发器可能会基于当前设计的假设而停止正常运行。正如你可以再次看到的，SQL服务器不关心你是否将你的主键从几列改变为某种类型的ID列。然而，程序代码逻辑和触发器以及其他在数据库系统中编写的内容可能非常关心这个问题。

而且在该数据库内设计的大量连接显然会有多个用于表之间连接的列。你将不得不去混乱找到所有这些连接，而不仅仅是重新制定约束，但其他RI（参照完整性）选项（如级联删除等）也很可能基于这些多列连接。

虽然大多数情况下级联删除可能可以改变没有问题，但实际上可能会通过转换为单列加入丢失一些级联删除限制逻辑。更有问题的是，如果您更改当前设计，则对子表进行的删除限制可能无法毫发无损地通过。

例如，如果客户仍有发票数据，则不能从系统中删除客户。然而，目前的系统实际上可能是您实际上可以删除一个有发票和客房预订的客户，而且他们必须年龄大于一年。再一次，它可能是某种复合键，它可以防止系统中某些东西被删除。你把这个改成单个连接，再一些你的程序逻辑甚至是一些基于SQL服务器端的3件东西删除限制约束可能会很好的分解。

所以，你的问题归结为所有当前的编程约束，甚至在SQL服务器端都是基于一组规则和假设，我们都是围绕这些键和约束的复合列进行设计的。因此，即使不查看ms-access客户端应用程序部分，您也必须查看服务器端的事物，并且现在可以了解两个不同的应用程序正在发生什么。

除非你的团队中的某个人熟悉这个软件的操作，并且代码基于两个系统，否则通过混淆这些关系和PK结构可能会产生太多的风险和缺陷。这成为高风险。数据结构的小改动可能会导致错误，这些错误可能需要数小时甚至数天才能在具有许多功能的应用程序中跟踪。

如果这只是一些表格，并且没有应用程序，也没有编写代码，那么这将是一项更容易的任务。

但是，通过与桌面关系和约束甚至结构混搭来尝试和重新构造应用程序，而应用程序应该运行并使用该数据运行是一项非常艰巨的任务。你最大的问题在于你如何知道你不会引入错误？

即使您正在制作一份未在生产中的应用程序，那么您将会进行修改，并且您将不会收到有关是否有问题甚至被破坏的反馈。

此问题不仅限于访问，还会在服务器端代码中引入风险。