Database *friendly* would be making a column for Name and a column for Phone so that other tables in the database could do things like joins on the data.
unless you don't know what the column names are, or how many columns there will be, which is the case with the example you're using.
My perspective is clouded by being more comfortable on a sql> prompt than in a PHP file, but serialized data in the DB makes me shudder nearly every time I see it.
i've never understood why serialization gets such a bad rap. it's just merely one technique that has it's own particular advantages and disadvantages--retrieval of data via sql queries being a weakness in this case... :) but it also allows for a certain on-the-fly flexibliliy and ease of use that trying to table-ize everything doesn't.
Sorry for the relatively OT rant, but while there are shortcut benefits on the PHP side to doing things like serializing data and storing it in the DB it can lead to inefficiencies and handcuffs in the long run. Databases tend to go really slowly for queries that look like...
agreed. but also, some implementations (like the signup form when it was designed) aren't focused on that kind of data retrieval, and have their own needs. in the case of the signup form, i needed a straightforward way to store themable form data for later display, so serialization was a logical choice. my view is that every tool probably has an appropriate situation where it's useful, including the much-maligned serialization of data... :)