Реализация отдельных увеличивающихся первичных ключей в Django

Question

Я разрабатываю внутреннее приложение для компании, в которой я работаю, и хочу использовать Django для его изучения и Python в целом, однако я столкнулся с проблемой с PK.

Я пытаюсь эмулировать часть текущего приложения, где 2 таблицы MySQL, TaskCategory и Tasks, выполняют задачи, которые необходимо выполнить.Каждая задача принадлежит категории TaskCategory, и у каждого элемента в TaskCategory есть свой собственный отдельный номер приращения.Таким образом, если «Офис» имеет 15 задач, добавление к нему другой задачи приведет к ее Task.taskid = 16, а добавление задачи к «Транспортным средствам» приведет к созданию Tasks.taskid = 51, а не 17. Затем он будет использоваться какномер отслеживания, например, задача «Транспортные средства-51».

Это отдельное увеличение было достигнуто благодаря наличию сложного первичного ключа в задачах, состоящего из taskcategoryid и taskid (которые автоматически увеличиваются).Кстати, Tasks.taskcategoryid - это не FK (я не думаю, что это может быть так или иначе, поскольку это часть составного PK).

Поскольку Django не нравится больше, чем 1 PK column I 'У нас были некоторые трудности с копированием этой функции.Я пробовал unique_together из taskid (автоинкрементный PK) и taskcategoryid (FK), и я пробовал иметь 2 автоинкрементных столбца (id и taskid), но вы не можете иметь более одного автоинкрементного столбца.

Можно ли достичь этой функции увеличения с помощью Django?Я бы предпочел сделать это без необходимости взламывать исходный код, но сделаю это при необходимости.

Answer 1

Какова ваша цель здесь?

Если вы пытаетесь поддерживать совместимость таблиц между полями с более старым приложением, у вас будут проблемы, потому что (как вы заметили) Djangoне делает составные / составные ключи - он действительно предпочитает суррогатный ключ .Учитывая операции, которые допускает Django, и текущее мышление о «правильном» дизайне базы данных, суррогатные ключи имеют смысл.

Если все, что вы на самом деле пытаетесь сделать, это оставить большинство запросов одинаковыми (или в основном похожими)затем вы можете оставить существующие поля естественного / составного ключа в покое, но отбросить старое ограничение первичного ключа, добавить новый суррогатный ключ для Django, а затем добавить метаданные в свои модели, чтобы объявить, что поля, которыесоставляют старые составные ключи unique_together.Джанго интерпретирует это и добавит соответствующие уникальные индексы.Вам потребуется добавить некоторый код к созданию объекта для обработки увеличения / присвоения идентификаторов TaskCategory, но в конечном итоге все ваши старые отношения реализуются Django и базой данных.

В качестве примераВот часть модели из приложения, которое я собрал для отслеживания игроков в турнире по настольной игре:

class Player(models.Model):
    badge = models.IntegerField()
    name  = models.CharField( max_length = 99 )

class Round(models.Model):
    name  = models.CharField( max_length = 9 )
    number = models.IntegerField()

class Table(models.Model):
    round = models.ForeignKey( Round )
    number = models.IntegerField( 'table number')

    class Meta:
        unique_together = ( 'round', 'number' )

class Seat(models.Model):
    table = models.ForeignKey( Table )
    position = models.IntegerField( 'seat number' )
    player = models.ForeignKey( Player )

    class Meta:
        unique_together = ( 'table', 'seat' )

В этом случае я использую unique_together, чтобы гарантировать, что номера таблиц будут повторно использоваться для разных раундов.и что места за столом одинаковы, вы никогда не встретите одну и ту же комбинацию «круглый стол» и «место» более одного раза.