Django: Проверка наличия объекта в queryset (если еще)

ПРОБЛЕМА: Проблема, с которой я сталкиваюсь, - это получение цены опциона в выбор модель. Это потому, что в зависимости от того, какой другой опции также находятся в одной корзине, разные цены будут использоваться для создания общей суммы. Мне нужна помощь с queryset, который получает мне цену опции, если параметр имеет effector_option что само внутри такая же тележка, использовала это, в противном случае использует вариация только с установленным полем опции.

Приложение TempName модель состоит из:

class Section(models.Model):
    title = models.CharField(max_length=20)
    description = models.CharField(max_length=100)
    temp = models.ForeignKey(TempName, null=False)
    def __str__(self):
        return self.title
    def get_options(self):
        return self.option_set.all()

class Option(models.Model):
    name = models.CharField(max_length=120)
    section = models.ForeignKey(Section, null=False)
    def __str__(self):
        return self.name
    def get_variations(self):
        return self.variation_set.all()

class Variation(models.Model):
    name = models.CharField(max_length=60, blank=True, unique=True)
    price = models.DecimalField(max_digits=5, decimal_places=2)
    option = models.ForeignKey(Option, null=False)
    effector_option = models.ForeignKey(Option, null=True, blank=True, related_name='option_effected')
    def __str__(self):
        return self.name

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

внутри вариация модель, поле опция просто говорит мне, какой вариант вариация принадлежит. The effector_option поле в Varaition модель однако будет использована тележкой.

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

Приложение Корзина модель состоит из:

class Cart(models.Model):
    owner = models.ForeignKey(settings.AUTH_USER_MODEL, null=True, blank=True)
    creation_date = models.DateTimeField(verbose_name='creation date')
    checked_out = models.BooleanField(default=False, verbose_name='checked out')
    class Meta:
        verbose_name = 'cart'
        verbose_name_plural = 'carts'
        ordering = ('-creation_date',)
    def __str__(self):
        return unicode(self.creation_date)
    def get_selections(self):
        return self.selection_set.all()


class Selection(models.Model):
    cart = models.ForeignKey(Cart)
    option = models.ForeignKey(Option)
    @property
    def price(self):
        return 10

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

ЧТО Я ПРОБОВАЛ:

получить все варианты опции. Затем пройдите через каждую вариацию и проверьте, есть ли вариация.effector_option содержится в том же корзина. Если это так, отобразите эту цену, иначе отобразите цену в пределах изменения, где изменение.effector_option имеет значение null / не установлено.

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

6
database-normalization django django-models django-queryset normalization

1 ответов

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

я укушу, потому что я считаю, что решение этой проблемы-разработка программного обеспечения. Проблема здесь не в нормализации, и не в Джанго. Как вы решили организовать проблема. Полагаю, вы попали в несколько ловушек, о которых я расскажу по дороге. Сначала давайте некоторые определения, прямо здесь, начиная с вашей собственной...

  • раздел - группа параметров
  • опции - цена
  • вариация - попытка моделирования параметров, которые влияют на другие параметры

теперь у нас есть эта проблема? Некоторые из моих Option выбор может использоваться с другими Option выбор и влияет на цену! Хаос! Нам нужно Variation предоставить мета-правила для их взаимоотношения. Еще Вопросы! Больше логики! Возможно...

Ловушка 1

позволяя, как вещи выглядят на экране диск вашей модели данных

я предполагаю здесь, но использование слова Section и Option заставьте меня почувствовать, что вы организуете экран, а не базу данных. Чаще всего компании имеют модели, которые выглядят следующим образом...

  • Product - что-то продаем (name, base_price, options, option_sets)
  • OptionSet - группы опций, которые идут вместе как пакет сделки! Подумайте о экономии!(name, group, options, price, optionset_exclusions, option_exclusions)
  • Option - a la carte опции(name, group, price)
  • Purchase - то, что кто-то хочет купить (product, options, optionsets)

теперь вы можете сказать :" как насчет моих разделов!"Разделы могут быть чем-то таким же простым, как висит кусок метаданных от OptionSet и Option под названием group С CharField тип. При рендеринге в шаблоне вы можете группировать параметры / optionsets вместе по group. Вы можете использовать exclusions чтобы остановить людей от выбора конфликтующих Option и OptionSets на Product. Теперь весь этот shebang можно плюхнуть на страницу всего с 3 запросами (при правильном использовании prefetch_related) и Options/OptionSets можно просто добавить вместе, чтобы получить детерминированный цена.

ловушка 2

позволяя, как вы хотите, чтобы он работал предотвратить его от работы на всех

теперь, прежде чем вы запустите залп "это не может работать для меня, я снежинка!"(очень давно). Часто мы обнаруживаем, что то, как мы хотим, чтобы что-то работало, стоит на пути его работы.

старые руководители unix использовали для обсуждения достоинств согласованности, простоты и полноты. Консенсус заключается в том, что Простота лучше всего, даже если она не полная или последовательная. Ваше оригинальное решение похоже на использование сложности для достижения полноты. это ловушка!(спасибо Адмирал Акбар)

например, так работает бизнес моего / моего клиента, поэтому он должен работать таким образом

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

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

Вариант 1 даст вам скидку 10% на Вариант 2. У вас просто статические цены!.

это можно смоделировать в схеме выше, где общая цена равна цене варианта 1 + .9 (цены варианта 2). В этом случае мы просто взяли понятие Variation и сделал это данные, а не поведение. Гораздо проще. Его более гибким. Я имею в виду вы могли бы сделать некоторые сложные 3D Объемное исчисление цен и просто визуализация результата в вашей схеме продукта. Есть еще проблемы, которые нужно рассмотреть...

я не хочу делать всю эту конфигурацию вручную!

напишите себе команду управления Django, которая импортируется из электронной таблицы.

что делать, если цены или отношения между Options изменить?

большинство схем продукта / цены включают понятие _spec как Option_spec что позволяет захватить Точка Во Времени условия покупки. _spec записи подключены к Purchase на момент покупки. Это позволяет Option и OptionSet для изменения без изменения всех подключенных прошлых покупок.

и далее по списку...

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

3