我正在考虑一种主键索引的设计，它将重用已删除行中的主键值（在极端情况下几秒钟内。）在这种情况下，这是最有效的设计。
然而，它开辟了潜在的漏洞和安全漏洞。客户端可能仍具有已删除记录的旧密钥值。针对该密钥的请求可能返回由不同用户的同一用户拥有的行。根据应用程序的编写程度，可能会出现混乱。
它永远不应该是一个安全漏洞，如果应用程序授予对另一个用户拥有的行的访问权限，则该应用程序在任何情况下都是不正确的。然而，这可能使缺陷更明显或更容易被利用。我认为更大的问题是该行可能属于同一个用户，并且应用程序可能会以意想不到的方式运行，因为它不是客户端认为的行。
我可以通过向行添加重用计数器以一个字节为代价来缓解它，当删除后重用主键值时递增。我会把那个主要部分作为主键。现在，如果重用计数器匹配，则只能错误地访问一行，在256次重用中只能访问一次。该错误仍然存在，并且它不能替代正确检查用户是否应该访问该行，但至少它会无意中访问错误的行。
思想？
这不是典型的SQL数据库，而是自定义数据库，但原则是正交的。
答案 0 :(得分：2)
如果应用程序授予对另一个用户拥有的行的访问权限，则该应用程序在任何情况下都是不正确的。
你有这种颠倒。信息提供者决定谁可以看到它。就像文件的权限而不是 cat （1）一样，确定谁可以读取它，因此在对象的DBMS权限中确定谁可以读取它。如果同一个表的不同用户不应该看到彼此的行，请提供按用户ID过滤行的视图。
该行可能属于同一个用户，并且应用程序可能会以意外的方式运行，因为它不是客户端认为的行。
您的问题的答案就在于：如果标识符标识，则无法识别错误的内容。这不是客户认为的问题。这是数据库所说的的问题。
永远不要使用一个标识符来表示两件事。如果用户将它们识别为相同的东西，那么在不同的时间它们是相同的东西是可以的。但是，如果出于效率或编程方便的原因，它们是两个不同的共享标识符的东西，那么你会误导用户的内容是什么。这不公平，你知道吗？用户在没有误导数据库的情况下正确处理问题就足够了。
让您的标识符一劳永逸地识别。如果您将这一原则应用于您的情况，答案立即就会明确。