Джанго: Это хорошая идея использовать абстрактную базовую модель в этой ситуации? - PullRequest
Новая
       9

Джанго: Это хорошая идея использовать абстрактную базовую модель в этой ситуации?

2 голосов
/ 26 января 2010 
class Account(models.Model):
        identifier = models.CharField(max_length=5)
        objects = MyCustomManager()

        class Meta:
            abstract = True

class Customer(Account):
        name = models.CharField(max_length=255)

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

Ответы [ 2 ]

1 голос
/ 26 января 2010

Зависит от направления внешних ключей. Вы не можете иметь внешний ключ для абстрактного класса.

Может быть, это Общие отношения что вас интересует или внешние ключи в классах абстрактной модели .

Хотя обратите внимание, что наследование всегда является отношением is-a, в то время как обычное использование внешнего ключа подразумевает отношение has-a.

В вашем примере Customer не должен наследоваться от Account как клиент имеет учетную запись.

Примером наследования может быть Место , которое представляет собой Ресторан или Кинотеатр и т. Д.

Редактировать после комментария:

Что ж, в документации есть собственный раздел :

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

...

  • Менеджеры из абстрактных базовых классов всегда наследуются дочерним классом, используя обычный порядок разрешения имен Python (имена в дочернем классе переопределяют все остальные, затем идут имена в первом родительском классе и т. Д.). Абстрактные базовые классы предназначены для сбора информации и поведения, общих для их дочерних классов. Определение общих менеджеров является подходящей частью этой общей информации.
  • Менеджер по умолчанию в классе - это либо первый менеджер, объявленный в классе, если он существует, либо менеджер по умолчанию первого абстрактного базового класса в родительской иерархии, если он существует. Если менеджер по умолчанию явно не объявлен, используется обычный менеджер по умолчанию в Django.

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

И старайтесь не помещать все в один менеджер, просто чтобы иметь возможность использовать только один менеджер из множества классов.

1 голос
/ 26 января 2010

В этом случае у вас будет 1 таблица для клиента с идентификатором учетной записи, и если вы добавите работника, у него будет собственная таблица с идентификатором учетной записи.

Я думаю, вы, вероятно, хотите иметь единую таблицу с учетными записями и прикрепленными объектами клиентов, работников и т. Д.? Таким образом, вы никогда не перепутаете свои учетные записи.

...