SQL: What if serializing PHP array into string and put it into table cell?

The exact question. What if making relation one-to-many like this: store id's of many in one's field, if we interact with it quite seldom and no deletes in many table are expected.

Some other things

A have dishes. Dishes consist of Products. Products has their own price. What if I'd do it this way:

Products columns : { Id, Name , PricePerOne }


Dish columns: { 
    Id, 
    Name, 
    Content ( it is serialized [n x 2] PHP Array with ProductID and Amount of this product in each row)

And than unserialize it when necessarily and calculate the exact sum, querying from Products like this WHERE Id in ( ".explode(..)." ) or even caching this figure.

So, I must have said something wrong, but I don't need to compare this serialized string or even do something with it. It would simply be used in querying price. Actually that is quite close to relation one-to-many. I each one dish relates to few products. So, I simply store data about amount of products I need开发者_开发百科 it this exact dish record.

I would advise against serializing anything you intend to search, or use in a "WHERE" clause.

The only times I have serialized data to put in my database is for logging full sets of POST of GET variables for later debugging, OR for caching an array of data.

In each example, I don't need to make any comparisons in SQL to the serialized string.

You may THINK it's easier to work with serialized data, but you're just going to end up tearing out your hair when your app runs at a glacial rate. You're negating the entire purpose of using a database.

Sit back and rethink your app from the ground up BEFORE you start down this path.

I would garner that the overhead on executing requests on a serialized DB format vs a relational one such as SQL increases exponentially with the complexity of the query you are performing.

Not only that, error checking and performing any number of more complex processes (Join? Union?) would doubtless cause premature aging...