[wp-hackers] Grab a seat. On Delaying 2.2, separating tables

[Doug Stewart]

On 4/15/07, Matt Mullenweg <m at mullenweg.com> wrote:
> On 4/15/2007 Doug Stewart wrote:
> > They're fundamentally
> > different than each other and to cram them into the same table is a
> > bad notion, DB design-wise.
>
> Would you mind explaining why? It has worked quite well for us thus far.
>

Let's take a look at the posts table for a second.

What use is "post_parent" to a post, exactly?  I can plainly see the
value for hierarchical pages and even uploads, but not posts.  What
about post_mimetype?  No value there, either.

How about "pinged" for uploads?  What sort of sense does that make?
And "post_content" is synonymous with "upload description"?  You're
getting peanut butter in the floor cleaner, to mix two slightly
disparate cultural references...

You're carrying unnecessary (and confusing) information with each
object type you cram into the posts table.  The only reason that it
has worked quite well thus far is that people are confident enough in
the overall quality and direction of WordPress to commit vast amounts
of their own time, blood, sweat and tears to the proposition that
WordPress is worth developing.  It has resulted in some gnarly hacks
in the past and I'm sure there will be some in the future

Which is easier, "SELECT * FORM wp_posts WHERE post_type='post'" or
"SELECT * FROM wp_posts" (in a DB purist's dream)?  In the second
example, the table name is actually descriptive of what it contains
(or we could just rename it to wp_content or somesuch and be done with
it, I suppose).  The current WP example is _not_ descriptive and it
carries a ton of informational baggage with each additional post,
upload and page that authors create.

Posts and pages are intended for different ends, yes?  The Codex says
so.  They are _similar_ but they are not the same, nor should they be,
IMNSHO.  "Alikeness" is not a factor for inclusion in a DB schema -
"synonymous" errrm, -ness _is_.

For example:

Let's say I was happily categorizing "Cars I've Seen" in a database.
I create a table called "cars" and begin storing "Lambroghini",
"Bentley", "Ford", "AMC" and the date and location on which I've seen
each.  Sometime down the road, I decide I really want to track "Planes
I've Seen" as well, so I simply begin to add "Learjet", "Super 80",
"747", etc. into the "cars" table.  They're vehicles, sure, and I've
seen 'em just like I've seen the cars, but they're fundamentally
different from what I initially intended the "cars" table to house.
Anyone coming along after me is going to be in for some serious
headscratching before they can suss out just what the devil I was
doing.

I do not understand the resistance to good DB design.  Lumping pages
in with posts was a kludge and is one that could use righting should
we ever care to scrub the entire schema.

-- 
-Doug

http://literalbarrage.org/blog/