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

[Otto]

On Wed, Mar 24, 2010 at 4:43 PM, Potkanski, Jason
<jpotkanski at tribune.com> wrote:
> You can skip it for performance reasons when justified - that should be very rare.

I disagree and think that it's far more common than you think. JOINs
are bloody costly, and if your DB is truly normalized, then it often
takes far, far too many of those. And again, pulling 1 row is faster
than pulling 10, even if you only use one SELECT statement to do it.

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

So for the case of set_option, having it split the array into pieces
and then execute a dozen SQL INSERT statements to an external database
server is somehow faster than simply running a built-in, compiled,
function across the data? Your logic escapes me here.

Your solution is slower, in all cases. And the "advantage" of having
separated options is basically non-existent for anybody who isn't
accessing the database directly (outside of the WordPress
environment). It just doesn't make any sense to do it that way, as far
as I can tell.

-Otto