Продукт с несколькими вариантами

Я прохожу процесс создания веб-сайта электронной коммерции. Я работаю с Django и Postgresql для хранения продуктов.

Я столкнулся с проблемой множественных вариаций продукта. Специально работая с разными видами продуктов, где продукты разных типов могут иметь разные варианты. А вариация — это продукт, объединенный несколькими вариантами.

Я провел анализ и, наконец, нашел 2 решения, которые могли бы решить эту проблему для меня.

Первый — это создание нескольких таблиц, связанных друг с другом:

Товары

Вариации | Принадлежит: Продукт

Опции | Принадлежит:Продукты

Option_Values ​​| Принадлежит:Опции

Variation_Option_Values ​​| Принадлежит:Вариации| Принадлежит:Опции }| Принадлежит: Option_Values

Теперь недавно я наткнулся на HStore() для Postgresql, который позволяет хранить данные как ключ: значение в поле таблицы. Где я могу хранить параметры и их значения в одной таблице.

Это уменьшит количество таблиц и упростит реализацию.

Любые идеи о том, какой метод будет лучше с точки зрения скорости и эффективности запросов. Наряду с любыми предложениями по дизайну?


django postgresql database hstore
person mrb101    schedule 27.02.2016    source источник
comment
Вам нужно подумать о том, какие запросы вы будете делать. Использование таблиц даст вам свободу выполнять сложные запросы и иметь одинаковые свойства для всех продуктов. Если вы предпочитаете иметь больше свободы в том, какие свойства может иметь продукт, без необходимости запрашивать или группировать продукты по свойствам, тогда ключ-значение или даже поле json могут быть лучше.   -  person serg    schedule 28.02.2016
comment
Спасибо за ваш ответ. В настоящее время операции, о которых я мог думать, просты. Единственная часть, которая меня беспокоит, - это поиск значений. Например, цвет, размер, вместимость в случае смартфонов или даже детали в случае велосипеда. Было бы очень сложно выдавать эти запросы? Я прочитал документацию на веб-сайте Django, и процесс запроса кажется похожим на то, как мы запрашиваем обычные таблицы. но ни слова о производительности. еще одна вещь — это процесс добавления API в приложение.   -  person mrb101    schedule 28.02.2016

Ответы (1)


arrow_upward
1
arrow_downward

Запросы к Hstore медленнее, чем запросы к традиционной реляционной схеме, но сопоставимы с другими базами данных NoSQL.

Проблема будет в том, если вы хотите часто обновлять Hstore. Он потребляет много памяти, потому что весь словарь выгружается-изменяется-и сохраняется обратно в базу данных (парни из postgres улучшают это). Было бы бессмысленно использовать Hstore, если данные большие и требуют частого изменения. При простом поиске это не будет проблемой производительности. Однако, если вы можете хранить его традиционно, тогда выбирайте его.

Если вы считаете, что Hstore все еще полезен для вашего случая, загляните в django-hstore. Это может помочь вам хранить данные в стиле NoSQL (с помощью функции SCHEME).

person RA123    schedule 11.03.2016