I have a products database with multiple tables to store pricing (because of default pricing and optional override pricing per product colour), and I have CASE statements in my query to get the
* Original price of the product
* Sale price of the product, if it is on sale
I also need to calculate the DISCOUNT of the product if it is on sale. Before I try this, please see the breakdown of my existing SQL which works.
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.
The above code works (I have simplified it), and basically, the original price of the product is stored in the column alias “final_original_price”, and the sale price (which might be NULL) is returned as “final_sale_price”.
I now want to add an additional line to the SELECT to get the discount. I can’t use the existing fields in the actual table because I want those return values of “final_original_price” and “final_sale_price” to do the calculations.
e.g.
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.
The above does not work, as Postgresql returns “ERROR: column “final_original_price” does not exist at character…..”
So, clearly I can’t use the return value of the CASE. My questions on what solution to use:
1) Can I indeed use the return value of the case like I want to, above?
OR
2) Do I need to again plug in the case statement to my calculation? That means I need to repeat the CASE code and the query will look quite lengthy. If I have to, I’d do this, but I’m just wondering if there’s a better way.
OR
3) I could also store an additional field in the database to store the discount. This data would be redundant because my CMS would need to ensure that the field is updated whenever the price is updated. However it would save heavy calculations (if the above is considered heavy) on the front end which runs much more often than the backend CMS.
The above solutions are probably the easiest, but I am also wondering, if I had time to do this, are there any other solutions here that would be worth considering? For example would this be a good scenarios to write a “view”? Personally I have never set up a view and as far as I understand, the database-selection work is still happening in the background, but, if set up, would make the end query above simpler to understand from a developer’s point of view.
Many thanks!
use
The above does exactly what you asked for… if for some reason you don’t want to use it then plugin the
CASEstatements into the calculation (option 2 from your question).