добрый вечер!

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

мой анализ этого вопроса привел к двум решениям:

1.
discounts (id, disc_value NOT NULL DEFAULT 0, PRIMARY KEY (id)) // disc_value - значение в процентах
disc2cat(cat_id INT NOT NULL DEFAULT 0, disc_id INT NOT NULL DEFAULT 0, start_date TIMESTAMP DEFAULT NULL, expire_date TIMESTAMP DEFAULT NULL, PRIMARY KEY (cat_id, disc_id)) - для категории
disc2prod(prod_id INT NOT NULL DEFAULT 0, disc_id INT NOT NULL DEFAULT 0, start_date TIMESTAMP DEFAULT NULL, expire_date TIMESTAMP DEFAULT NULL, PRIMARY KEY (prod_id, disc_id)) - для продуктов

2.
discounts (id, disc_value NOT NULL DEFAULT 0, PRIMARY KEY (id)) // disc_value - значение в процентах
disc2prod(cat_id INT DEFAULT NULL, prod_id INT DEFAULT NULL, disc_id INT NOT NULL DEFAULT 0, start_date TIMESTAMP DEFAULT NULL, expire_date TIMESTAMP DEFAULT NULL, PRIMARY KEY (cat_id, prod_id, disc_id))

вопросы:

1. какой из вариантов самый оптимальный для введения скидок на продукты или для всех продуктов конкретной категории или для конкретных продуктов?
2. правильно ли и в полной мере ли заявлены уникальные поля в таблицах?

P.S. Пожалуйста, варианты с предоставлением скидки при оформлении, например нескольких товаров в корзине и о купонах не обсуждать - на данном этапе этот вопрос не актуален.

спасибо

" Странная какая-то у вас настроечная таблица" (Папа дяди Федора)

зачем таблица discounts? в чем её смысл? почему просто не указывать процент в таблицах?

_____________
Стимулятор ~yoomoney - 41001303250491

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

какие еще идеи по сути вопросов?

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

_____________
Стимулятор ~yoomoney - 41001303250491

Вот такой ещё вариант может быть.

Создать таблицу discounts (id, value, start_date, expire_date)
В таблицу products добавить поле discount_id
В таблицу categories добавить поле discount_id

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

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

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

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

спасибо

OleKh

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

спасибо за ответ. есть еще идеи?

Разрешите поинтересоваться ) почему многие считают не оптимальным этот вариант?

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

вот такой аргумент в пользу, выборка размера скидки понадобится при выводе списка товаров или карточки товара, т.е. через Select таблицы Products, в моем варианте есть к чему привязаться, а в варианте например №1 прийдется делать сложный запрос

OleKh

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

Здесь есть какая-то хитрость в оптимизации запросов. и от этого зависит оптимальная структура таблиц.

спасибо за ответ, буду благодарен за продолжение дискуссии

или ещё если в интернет-магазине будет к примеру 1 000 000 товаров, соответственно таблица disc2prod будет иметь 1 000 000 записей, если у каждого товара будет персональная скидка

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

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

спасибо

Вот так реализована таблица скидок в OpenCart, в VamShop значения добавляются в products и customers

product_discount_id
product_id
customer_group_id
quantity
priority
price
date_start
date_end