[development] serialized data in the DB Re: [support] signup_form_data

[Chad Phillips -- Apartment Lines]

> 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...  :)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20060713/e48e8b2e/attachment.htm