应用程序开发:我应该检查表上的主键还是假设它应该在那里?

确保查询实际上只从具有主键的表返回数据。如果此表与查询中的另一个表联接,并且不是一对一关系,则可能会导致返回多个在主表中具有相同ID的行。在这种情况下,检查重复的代码实际上可能在做一些有价值的事情。

只要不是这样,就删除检查重复项的代码。验证数据库是否正常工作是对CPU周期和内存的浪费。

我总是让DB来管理这个规则,因为它最擅长这样做。但是,当人们因为各种原因丢掉主键时,我就被咬了一口——但最好是分开处理,因为这通常是另一个问题的迹象(例如缺乏培训或护理)

我认为必须确认应用程序代码中的模式是正确的是个坏主意。这将是一个令人难堪的担忧的混合体。事实上,应用程序根本不应该关心模式——它应该依赖于一个抽象的数据模型。

验证是另一个问题。您应该主动检查主插入和唯一键控插入上的重复项,而不是依赖数据库异常来指示重复项。

我认为它应该被检查-但不是由应用程序。你可能不运行病毒检查,测试数据库中是否有足够的空间,获取硬盘运行状况。。。你的申请表上也有。

即使您确实从应用程序中检查了PKs,您怎么知道这一点没有改变 运行时间?PKs的存在应该由数据库部署过程来保证,并且权限要有足够的限制,不能在该过程之外(太容易)更改。

我不会检查它,这是一个非常基本的RDBMS原则。我不认为如果有人违反了你的代码,你的代码给出奇怪的答案是不合理的。

在我看来,检查主键上的重复项是多余的。也很蠢,但那是不礼貌的,所以让它去吧。

DBA不应禁用主键。

如果有人可能会在你的数据库中破坏东西,那么检查你的数据库结构是否完好无损是很重要的。

如果DBA将主键放在表中,而产品团队没有意识到这一点来进行适当的代码更改,那么这并不是代码的缺点。我确信没有DBA会这么做。所以,检查表是否有PK是绝对多余的。

对于生产应用程序,通常还需要实现变更管理过程,以便在发布之前对任何变更(无论是应用程序还是数据库)进行回归测试。