[development] serialized data in the DB Re: [support]
Chad Phillips -- Apartment Lines
chad at apartmentlines.com
Thu Jul 13 18:52:16 UTC 2006
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the development