У меня есть база данных продуктов с несколькими таблицами для хранения цен (из-за цены по умолчанию и дополнительной переоценки цены на цвет продукта), и у меня есть предложения CASE в моем запросе, чтобы получить * Исходная цена продукта * Продажная цена продукта, если он продается
Мне также нужно рассчитать СКИДКУ продукта, если он продается. Прежде чем я попытаюсь это сделать, см. Разбивку моего существующего SQL, который работает.
SELECT p.productid, p.stylename,
CASE WHEN (ppo.original_price IS NOT NULL) THEN ppo.original_price ELSE pp.original_price END AS final_original_price,
CASE WHEN (ppo.original_price IS NOT NULL) THEN ppo.sale_price ELSE pp.sale_price END AS final_sale_price
FROM product p, ... etc.
Приведенный выше код работает (я упростил его), и в основном первоначальная цена продукта хранится в псевдониме столбца "final_original_price", а цена продажи (которая может быть NULL) возвращается как "final_sale_price".
Теперь я хочу добавить дополнительную строку в SELECT, чтобы получить скидку. Я не могу использовать существующие поля в фактической таблице, потому что для выполнения вычислений мне нужны те возвращаемые значения final_original_price и final_sale_price.
например.
SELECT p.productid, p.stylename,
CASE WHEN (ppo.original_price IS NOT NULL) THEN ppo.original_price ELSE pp.original_price END AS final_original_price,
CASE WHEN (ppo.original_price IS NOT NULL) THEN ppo.sale_price ELSE pp.sale_price END AS final_sale_price,
((final_original_price - final_sale_price) / final_original_price * 100) AS final_discount_percentage
FROM product p, ... etc.
Вышеприведенное не работает, поскольку Postgresql возвращает "ERROR: столбец" final_original_price "не существует символа....."
Итак, я не могу использовать возвращаемое значение CASE. Мои вопросы о том, какое решение использовать:
1) Могу ли я использовать возвращаемое значение для случая, как я хочу, выше? ИЛИ 2) Нужно ли мне снова подключить оператор case к моим расчетам? Это означает, что мне нужно повторить код CASE, и запрос будет выглядеть довольно длинным. Если я должен, я бы сделал это, но мне просто интересно, есть ли лучший способ. ИЛИ 3) Я мог бы также сохранить дополнительное поле в базе данных для хранения скидки. Эти данные будут избыточными, поскольку моя CMS должна будет гарантировать, что поле будет обновляться всякий раз, когда цена будет обновлена. Однако это сэкономит тяжелые расчеты (если выше считается тяжелым) на переднем конце, который работает гораздо чаще, чем бэкэнд CMS.
Вышеупомянутые решения, вероятно, самые легкие, но мне также интересно, если бы у меня было время сделать это, есть ли здесь какие-то другие решения, которые стоит рассмотреть? Например, это будет хороший сценарий для написания "представления"? Лично я никогда не настраивал представление и, насколько я понимаю, работа по выбору базы данных все еще происходит в фоновом режиме, но, если она настроена, сделает конечный запрос выше более понятным с точки зрения разработчика.
Большое спасибо!