Каковы полные последствия того, что не используется первичный ключ id по умолчанию в вашей модели Django?

Question

Рассмотрим случай, когда поле CHAR primary_key требуется для определения отношения ForeignKey.

После некоторого первоначального исследования я определил следующие возможности, каждая из которых имеет свои недостатки:

1) Использование «primary_key = True».

Example 1:

class Collection(models.Model):
    code = models.CharField(primary_key=True, max_length=3)

class Item(models.Model):
    code = models.CharField(primary_key=True, max_length=255, unique=True)
    collection = models.ForeignKey('Collection', related_name='items')

Потенциальный недостаток: Может привести к проблемам при включении сторонних приложений, так как некоторые сторонние приложения django зависят от целочисленного поля по умолчанию «id» PK.

2) Вместо этого используйте параметр 'to_field' / 'through'.

Example 2:

class Collection(models.Model):
    code = models.CharField(Max_length=3, unique=True)

class Item(models.Model):
    collection = models.ForeignKey('Collection', to_field='code', related_name='items')

Это позволит 'Collection' иметь собственный идентификатор primary_key, поэтому она решает проблему приятной игры с приложениями django сторонних производителей.

Потенциальные недостатки: После дальнейшего изучения я обнаружил следующие открытые билеты и ошибки в Django ORM, касающиеся работы со смесью CHAR / INT primary_keys в FK и отношениями многие ко многим.

http://code.djangoproject.com/ticket/11319 и 13343

Вывод:

Вариант 1 лучше, чем Вариант 2.
Однако:
Много ли сторонних приложений зависит от целого числа primary_key?
Есть ли простой способ обойти это ограничение?
Есть ли другие недостатки, использующие CHAR primary_key?

Answer 1

У меня были проблемы в приложении администратора django при использовании поля char в качестве первичного ключа. См. ошибка Unicode при сохранении объекта в администраторе django для получения подробной информации

Восстановление идентификатора в качестве первичного ключа было затруднительным, см. Каков наилучший подход для изменения первичных ключей в существующем приложении Django? .

Исходя из этого опыта, я думаю, что использование чего-то другого, кроме идентификатора в качестве первичного ключа, является плохой идеей.

Answer 2

GenericForeignKey s пострадают, поскольку все они должны использовать один и тот же тип для иностранного ПК.Пока вы держитесь от них подальше, с вами все будет в порядке.

Answer 3

Лично я выбираю вариант 2 в своих приложениях, поскольку именно так я видел большинство сторонних приложений, и это позволяет избежать множества проблем, которые вы уже затронули в своем посте в отношении смешивания CHAR и INT. Основные ключи в Django ORM.

Я еще не сталкивался ни с одной проблемой, просто используя unique=True, поэтому я не вижу никаких недостатков в этом.