python Django 或类似的复合主键
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1624257/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Django or similar for composite primary keys
提问by Matthew DeNardo
I am writing a web application for my engineering company (warning: I am a programmer only by hobby) and was planning on using Django until I hit this snag. The models I want to use naturally have multi-column primary keys. Per http://code.djangoproject.com/ticket/373, I can't use Django, at least not a released version. Can anyone help me with a workaround, whether it be via another web framework (Python-based only, please) or by suggesting changes to the model so it will work with Django's limitations? I am really hoping for the latter, as I was hoping to use this as an opportunity to learn Django.
我正在为我的工程公司编写一个 Web 应用程序（警告：我只是业余爱好的程序员）并且计划使用 Django，直到我遇到这个障碍。我想使用的模型自然有多列主键。根据http://code.djangoproject.com/ticket/373，我不能使用 Django，至少不是发布版本。任何人都可以帮助我解决方法，无论是通过另一个 Web 框架（请仅基于 Python）还是建议对模型进行更改，以便它可以与 Django 的限制一起使用？我真的希望是后者，因为我希望以此作为学习 Django 的机会。
Example: Table one has part_number and part_revision as two fields that should comprise a primary key. A P/N can exist at multiple revisions, but P/N + rev are unique.
示例：表一将 part_number 和 part_revision 作为两个字段，应该包含一个主键。AP/N 可以存在于多个修订版中，但 P/N + rev 是唯一的。
Table two has part_number, part_revision and dimension_number as its primary key. A P/N at a specific rev can have a number of dimensions, however, each is unique. Also, in this case, P/N + rev should be a ForeignKey of Table one.
表二以part_number、part_revision和dimension_number为主键。特定转速下的 AP/N 可以有多个维度，但是，每个维度都是唯一的。此外，在这种情况下，P/N + rev 应该是表一的外键。
回答by Dominic Rodger
Why not add a normal primary key, and then specify that part_numberand part_revisionas unique_together?
为什么不添加一个普通的主键，然后指定那个part_number和part_revision作为unique_together？
This essentially is the Djangoish (Djangonic?) way of doing what Mitch Wheat said.
这本质上是做 Mitch Wheat 所说的 Djangoish (Djangonic?) 方式。
回答by Mitch Wheat
A work around is to create a surrogate key (an auto increment column) as the primary key column and place a unique index on your domain composite key.
解决方法是创建一个代理键（一个自动增量列）作为主键列，并在域复合键上放置一个唯一索引。
Foreign keys will then refer to the surrogate primary key column.
然后外键将引用代理主键列。
回答by shanyu
I strongly suggest using a surrogate key. Not because it is "Djangoesque". Suppose that you use a composite key that includes part_number. What if some time later your company decides to change the format (and therefore values) of that field? Or in general terms, any field? You would not want to deal with changing primary keys. I don't know whatever benefit you see in using a composite key that consists of "real" values, but I reckon it isn't worth the hassle. Use meaningless, autoincremented keys (and that should probably render a composite key useless).
我强烈建议使用代理键。不是因为它是“Djangoesque”。假设您使用包含 part_number 的复合键。如果一段时间后您的公司决定更改该字段的格式（以及值）怎么办？或者一般来说，任何领域？您不想处理更改主键。我不知道使用由“真实”值组成的复合键有什么好处，但我认为它不值得麻烦。使用无意义的、自动递增的键（这可能会使复合键变得无用）。
回答by Denis Otkidach
SQLAlchemy has support for composite primary and foreign keys, so any SQLAlchemy based framework (Pylons and Werkzeug comes to mind) should suite your needs. But surrogate primary key is easier to use and better supported anyway.
SQLAlchemy 支持复合主键和外键，因此任何基于 SQLAlchemy 的框架（想到 Pylons 和 Werkzeug）都应该满足您的需求。但无论如何，代理主键更易于使用和更好的支持。
