Django or similar for composite primary keys

Question

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.

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.

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.

Answer 1

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.

Answer 2

Why not add a normal primary key, and then specify that part_number and part_revision as unique_together?

This essentially is the Djangoish (Djangonic?) way of doing what Mitch Wheat said.

Answer 3

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).

Answer 4

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.

Answer 5

Thanks for the replies. I now understand why I should look at surrogate keys and how they are implemented. Extra thanks to celopes for the linked article.