запросов и постраничных три типа моделей в то же время в Джанго

Question

В Джанго У меня есть три модели:

• SimpleProduct
• ConfigurableProduct Вместо того чтобы показывать несколько вариантов SimpleProducts, пользователь увидит один продукт с параметрами подобный цвет.
• GroupProduct - несколько простых продуктов, которые продаются вместе.

Сначала я создаю все SimpleProducts, затем создаю ConfigurableProducts из нескольких продуктов, которые являются вариациями одного и того же продукта и последних GroupProducts, которые являются комбинациями нескольких SimpleProducts.

Когда пользователь переходит к категории, мне нужно показать ему все три типа. Если SimpleProduct является частью ConfigurableProduct, я не хочу показывать его дважды.

Как сделать запрос? Должен ли я создать три запроса? Как использовать разбиение на страницы трех моделей одновременно? Могу ли я как-то использовать наследование?

Благодаря

Answer 1

Я думаю, что этот вопрос трудно ответить, не понимая вашу бизнес-логику немного более четко. Вот мои предположения:

1. Конфигурируемых варианты специальные, т.е. вы продаете шары в красных, синих и желтых, рубашках в малых, среднем и большом, и т.д. Там нет никакого способа, чтобы представить эти варианты отвлеченно потому что они не превосходят категории. (Если бы это было так, ваш дизайн базы данных был бы неправильным. Если бы у всех были пользовательские параметры цвета, вы просто сделали бы это столбец в своей таблице базы данных.)
2. Каждый вариант конфигурации имеет уже существующую фирменную идентификацию в вашей компании. Есть некоторые ску, связанные с красными шарами или что-то в этом роде. По какой-то причине необходимо иметь строку базы данных для каждой возможной опции конфигурации. (Если это не так, опять же, вы делаете все это неправильно.)

Если это так, моей самой простой рекомендацией было бы иметь некоторый базовый класс, который все продукты наследуют с помощью поля: representative_product_id.Идея заключается в том, что для каждого продукта существует репрезентативная версия, которая отображается на странице категории или где-либо еще в вашем каталоге. В базе данных, это будет выглядеть следующим образом:

Name   id representative_id 
red_ball  1  1 
blue_ball  2  1 
green_ball 3  1 
small_shirt 4  4 
medium_shirt 5  4 
large_shirt 6  4 
unique_thing 7  7 

Что касается Джанго запросов, я хотел бы использовать F objects, если у вас есть версии 1.1 или более поздней версии. Просто:

SimpleProduct.objects.filter(representative_id=F('id')) 

Это вернет запрос, чьи представительские идентификаторы соответствуют их идентификаторам.

На данный момент кто-то будет требовать целостности данных. Главное условие состоит в том, что representative_id должен во всех случаях указывать на объект, representative_id соответствует его id. Есть способы принудительного применения этого непосредственно, например, с помощью валидатора pre_save или что-то в этом роде. Вы также можете сделать то же самое, разложив таблицу ProductType, содержащую столбец representative_id. Т.е .:

Products 
Name   id product_type 
_________________________________ 
red_ball  1  ball 
blue_ball  2  ball 
green_ball 3  ball 
small_shirt 4  shirt 
medium_shirt 5  shirt 
large_shirt 6  shirt 
unique_thing 7  thing 

Types 
Name   representative_id 
_______________________________ 
ball   1 
shit   4 
thing   7 

Это не отменяет необходимость обеспечения целостности с некоторым валидатором, но это делает его немного более абстрактным.

Answer 2

Go с Джанго multi-table inheritance, с базовым классом вы не будете напрямую создание экземпляра. У базового класса по-прежнему есть менеджер, с которым вы можете запускать запросы, и это будет содержать базовые атрибуты любого экземпляра подкласса.

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

• Make конфигурируемых продуктов множественный выбор из ConfigurableProductChoice (не связанный с SimpleProduct). Пусть ConfigurableProductChoice расширяет ConfigurableProduct. Таким образом, у вас будет один ConfigurableProduct в ваших результатах и ​​отсутствие избыточности.
• Сделать настраиваемые продукты связанными с различными параметрами и разработать правило для вычисления цены из выбранных опций. Простое дополнение будет в порядке. Идентификаторы продуктов должны будут кодировать, какие параметры выбраны. У вас все еще нет избыточности, потому что вы не использовали SimpleProduct.