Leetcode Rearrange Products Table Medium Level - mysql

Question

I saw one answer in discussion as below
SELECT A.product_id, B.COLUMN_NAME as store,
CASE
WHEN B.COLUMN_NAME = "store1" THEN store1
WHEN B.COLUMN_NAME = "store2" THEN store2
WHEN B.COLUMN_NAME = "store3" THEN store3
END AS price
FROM Products A, INFORMATION_SCHEMA.COLUMNS B
WHERE table_name = 'Products' AND column_name != "product_id"
HAVING price IS NOT NULL
Can someone please explain how can we write this INFORMATION_SCHEMA and could still get the output. This is in MYSQL

Answer 1

A couple of techniques are used to pull this off:
Cross Join: Instead of joining the two tables on a key, instead the OOP is joining every record of Products with every records of INFORMATION_SCHEMA.COLUMNS (where the column_name isn't product_id). Essentially they are making an intermediate result set that looks like:
+------------+--------+--------+--------+------------+-------------+
| product_id | store1 | store2 | store3 | table_name | column_name |
+------------+--------+--------+--------+------------+-------------+
| 0 | 95 | 100 | 105 | Products | store3 |
| 0 | 95 | 100 | 105 | Products | store2 |
| 0 | 95 | 100 | 105 | Products | store1 |
| 1 | 70 | | 80 | Products | store3 |
| 1 | 70 | | 80 | Products | store2 |
| 1 | 70 | | 80 | Products | store1 |
+------------+--------+--------+--------+------------+-------------+
You can see each row of products is triplicated as there are three rows of column metadata in INFORMATION_SCHEMA.COLUMNS.
A Case Expression to generate a new column on this intermediate result set that pulls the correct store column's int value based on the INFORMATION_SCHEMA.COLUMNS.column_name for that row:
SELECT A.*, B.COLUMN_NAME as store,
CASE
WHEN B.COLUMN_NAME = "store1" THEN store1
WHEN B.COLUMN_NAME = "store2" THEN store2
WHEN B.COLUMN_NAME = "store3" THEN store3
END AS price
FROM Products A, INFO_SCHEMA B
WHERE table_name = 'Products' AND column_name != "product_id"
HAVING price IS NOT NULL;
+------------+--------+--------+--------+--------+-------+
| product_id | store1 | store2 | store3 | store | price |
+------------+--------+--------+--------+--------+-------+
| 0 | 95 | 100 | 105 | store3 | 105 |
| 0 | 95 | 100 | 105 | store2 | 100 |
| 0 | 95 | 100 | 105 | store1 | 95 |
| 1 | 70 | | 80 | store3 | 80 |
| 1 | 70 | | 80 | store1 | 70 |
+------------+--------+--------+--------+--------+-------+
I included the original columns from Products table to show what the case expression is doing.
The sneaky HAVING clause tossed on at the end. Because the price columns derived by the case expression doesn't exist at the point of query execution when the WHERE clause is executed, OOP snuck in this HAVING clause which evaluates near the end of the sql execution steps when the price column was made into existence. The reason I say it's sneaky is because HAVING without a GROUP BY or any aggregation at all is an oddball and may fail in other RDBMS (but I'd have to test).