我应该在SQL中避免使用代理主键吗？

Question

短篇小说
我手上有第三方库的技术问题，除了创建代理键之外我似乎无法轻易解决（尽管事实上我永远不需要它）。我已经阅读了网上的一些文章，不鼓励使用代理密钥，如果可以做我打算做的事情，我有点不知所措。

长篇故事
我需要指定一个主键，因为我使用SQLAlchemy ORM（需要一个），我不能只在__mapper_args__中设置它，因为该类是用classobj构建的，我还没有找到方法在适当的PK定义参数中引用尚未存在的类的字段。另一个问题是PK的自然等价物是一个复合键，对于我使用的MySQL版本来说太长了（而且无论如何使用这么长的主键通常都是个坏主意。）

Answer 1

我总是在使用ORM时制作代理键（或者更确切地说，我让ORM为我制作它们）。它们解决了许多问题，并没有引入任何（重大）问题。

所以，你已经完成了自己的工作，承认网上有“论文”，并且有正当理由避免代理密钥，而且可能有更好的方法。

现在，在源代码的某处写下“# TODO: find a way to avoid surrogate keys”，然后完成一些工作。

Answer 2

“使用代理键允许在使用自然键时创建重复项可以防止出现此类问题”确切地说，您应该拥有两个键，而不仅仅是代理。您似乎犯的错误并不是您使用代理，而是您假设表只需要一个密钥。确保您创建了确保数据完整性所需的所有密钥。

话虽如此，在这种情况下，似乎ORM软件（显然无法使用复合键）的缺陷是导致问题的真正原因。不幸的是，像这样的软件限制会迫使你创建你不需要的密钥。也许你可以考虑使用不同的软件。

Answer 3

我在使用sqlalchemy反射的数据库中使用代理键。专家是您可以更轻松地管理表/模型中存在的外键/关系。此外，rdbms正在更有效地管理数据。 con是数据不一致：重复。为避免这种情况 - 始终使用自然键上的唯一约束。

现在，我从长篇故事中了解到，由于您的mysql限制，您无法强制执行此唯一性。对于长复合键，mysql会导致问题。我建议你转到postgresql。