Django: уникальные идентификаторы для таблиц

#python #django #django-models #uuid

#python #django #django-модели #uuid

Вопрос:

Мне было любопытно, есть ли хорошее решение для реализации уникальных идентификаторов между таблицами.

 class Voice(models.Model):
    id = ..          <------|
    slug = ...              |
    name = ....             |-- No duplicate IDs
                            |
class Group(models.Model):  |
    id = ..          <------|
    slug = ...
    name = ....
 

Я надеюсь, что когда я получу идентификатор в представлении, выбор из одной модели не даст мне ничего, но другая всегда будет возвращать объект (и наоборот). Если есть лучший подход, не стесняйтесь делиться. Прямо сейчас я использую slug id в качестве фильтров запросов, но хотел бы отойти от этого.

Комментарии:

1. Это похоже на проблему xy , почему они разделяют модели, если они так тесно связаны?

Ответ №1:

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

 class NewCommonModel(models.Model):
    # common fields go here.

class Voice(models.Model):
    new_common_model = models.OneToOneField(NewCommonModel, on_delete=models.CASCADE)
    # voice specific fields


class Group(models.Model):
    new_common_model = models.OneToOneField(NewCommonModel, on_delete=models.CASCADE)
    # group specific fields
 

Комментарии:

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

Ответ №2:

Определите идентификатор как целочисленное поле вместо auto. Voice всегда имеет четные числа в качестве идентификатора, а Group всегда нечетная. Таким образом, вы даже заранее будете знать, в какой модели вам следует искать

Ответ №3:

Я бы рекомендовал использовать uuid в качестве первичного ключа. Решает вашу уникальную проблему, запутывает ваш пк, уникален во всей вселенной и также встроен в django.

Поскольку вы упомянули slug, есть способы создать уникальный slug для каждой модели, где вам никогда не нужно будет создавать составной ключ с помощью pk. Или вы можете включить slug в URL-адрес по косметическим причинам и просто фильтровать в своем представлении только pk, который всегда должен быть уникальным.

Но обычно наличие одного и того же pk в двух моделях на самом деле никогда не должно быть проблемой, и, не зная больше, я был бы обеспокоен тем, что вы делаете что-то странное.