I see that people store arrays as like:
a:6:{i:0;s:5:\"11148\";i:1;s:5:\"11149\";i:2;s:5:\"11150\";i:3;s:5:\"11153\";i:4;s:5:\"11152\";i:5;s:5:\"11160\";}
I've not seen this a whole lot. But it's clearly done for implementation ease. Serializing data allows to store quasi binary data.
Your second example is a CSV
scheme. This is workable for storing confined string lists. While it's easier to query or even modify within the database, it makes more effort for unmarshalling from/to the database API. Also there is really only limited list
support anyway. http://dev.mysql.com/doc/refman/5.1/en/string-functions.html#function_find-in-set
However, true, the serialized data is unneeded in your example. It's only a requirement if you need to store complex or nested array structures. And in such cases the data blob is seldomly accessed or queried within the database.