I am working on a website(PHP), and one of the features that the site should have is ordering items from the website, and the order will be like an array with an architecture similar to this:
order( item1(item id, quantity) item2(item id, quantity))
And i want to know what is the optimal way to store the order, i came up with two ways to do that,
The first way which seems the easiest and simplest to me is by Using
serialize() and storing the values in a single cell in the same table as the rest of the order information,
The second way is to make a new table with three columns, one for the order id, the second for the item id and the third for the quantity, so this way if the user submits an order with * number of items i will have * number of rows for the order in the order items table.
When searching about the best way to do that i discovered the the first way is basically blasphemy in an SQL database and that the second way is the correct way, but is it really applicable for all cases, i mean in my case i don't foresee a situation where i wont request all of the order or need queries to be done on an individual item in an order, I am leaning to chose the first way and blame it on Occam's razor, since for my website it seems like the simplest answer, is there something that i am not seeing(I mean i admittedly have little experience in coding let alone databases) which explains all the hate for this way? performance wise i mean.