[wp-hackers] How do you store multiple plugin options

[Potkanski, Jason]

On 3/24/10 3:58 PM, "Otto" <otto at ottodestruct.com> wrote:


>> You didn't address the database denormalization issue. That's a severe one.
>> If plugin developers are not going to normalize their data, why use the blog
>> options table at all? Use a flat file.
>
> WordPress does not use "normalized" database design in any sense of
> the term. IMO, normalization is a crutch for bad development practices
> and an excuse to give DBA's too much power that they frankly should
> never have been allowed to have in the first place.

DBAs on power trips are common for various other reasons. I have never seen anyone argue that normalization is a crutch or bad thing. You can skip it for performance reasons when justified - that should be very rare.


>> Not sure if you need the separate table.
>>
>> I would propose the a new define "WP_NORMALIZE_DB" or some such which would
>> use different version of the get/update/set_option functions that wouldn't
>> serialize the data. It would probably require an addition to the schema
>> options table of a 'child' column so that it relates to a master option.
>
> Negative. That would make plugin programming far more complex, as now
> it would have to account for both cases and do it's own
> (un)serialization when the user had enabled that. Very bad way to do
> things.

Set/get/update/wp_load_options/wp_options could be rewritten to not use serialization and provide a one stop point for disassembly and reassembly of an array of options from the db and back without relying on the plugin to do it. Probably two additional columns to the options table.