Запрос и разбиение на страницы трех типов моделей в Django одновременно

Question

В Django у меня есть три модели:

• 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

Что касается запросов django, я бы использовал 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

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

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

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