[wp-hackers] Term Meta - Trac'd already?

[Mike Schinkel]

On Jul 13, 2011, at 4:43 PM, Otto wrote:
> The problem as I see it is one of efficiency. How many layers can you
> add to the dream before falling into limbo? When you start having to
> pull meta from the database, then to pull meta for the meta, you start
> making more and more queries. This makes your code more complex and
> fragile. Prone to breakage from new core changes. That sort of thing.

You have a great point in general.  Where we differ is that you limit to one level of meta and I think we really need two (btw what we are talking about here is really meta on taxonomy, not taxonomy on taxonomy, at least not for this discussion.)  

For example, if we have posts about cities and "San Francisco" I can see having a lot of related info about San Francisco to be displayed at the "/san-fran/" URL such as a city positioning statement, a broad description, photos, a history of the city, geo-cordinates, lists of amenities, etc. etc.:

http://example.com/category/san-fran/

However as I write this it reminds me that what we have in fact is the need for a custom post type associated with the San Francisco category meaning that either having said relationship easily available has merit (or even turning term_taxonomy into a post itself.) I and others have proposed a variety of these types of things in the past on this list and on trac.  But in many cases just having meta for term_taxonomies would be sufficient.

In a nutshell, the current toolset is missing a tool and that's why this issue keeps coming up.

> Yes, your perspective is all very database relational model and such,
> but at some point, you have to sit back and re-examine what it is that
> you're building here. You may have noticed that the WP database is
> pretty far from 3rd normal form, but it's fast for the specific case
> of serving a webpage. If you start adding layers, you rapidly build a
> "correct" site, ... and which can be so slow as to be useless.

To be clear, I greatly respect and admire the structure WordPress has even though I came from a strict relational model. I have seen both ends of the spectrum and this that what WordPress has is scalable in complexity whereas a highly 3rd normal form database is not. The "posts" structure is the same as Drupal's "node" structure so I think that recognizes an important pattern.

> There's specific cases where tricks like this are useful, but I
> consider them to be just that: tricks. One-offs. Not necessarily a
> good base upon which to build a system. Honestly, sometimes it's
> better to just make a new database for your specific data instead of
> trying to shoehorn things into the WP data format. Depending on the
> data and the use case, of course. Most cases can be fit into custom
> post types and meta and taxonomies, without additional layers on top.
> Maybe not all cases, but in such cases it's worth asking if that data
> structure should live in the WP formats at all, or get its own custom
> tables.

In general, I also agree. 

So I don't think going all 3rd normal form is required or even desirable, I just think we are missing a few key building blocks for non-blog use-cases.  

-Mike
P.S. (But it's all okay by me. We are working to solve those use-cases on behalf of clients, but in a generic way and we will make that code GPL and freely downloadable once it's ready for public consumption. This is part of what I told you about when you were in Atlanta.)

On Jul 13, 2011, at 4:43 PM, Otto wrote:

> On Wed, Jul 13, 2011 at 3:28 PM, Mike Schinkel
> <mikeschinkel at newclarity.net> wrote:
>> But just because something describes something doesn't mean that it doesn't also need to be described; that's there the concept of "meta meta" comes from.
> 
> The problem as I see it is one of efficiency. How many layers can you
> add to the dream before falling into limbo? When you start having to
> pull meta from the database, then to pull meta for the meta, you start
> making more and more queries. This makes your code more complex and
> fragile. Prone to breakage from new core changes. That sort of thing.
> 
> Yes, your perspective is all very database relational model and such,
> but at some point, you have to sit back and re-examine what it is that
> you're building here. You may have noticed that the WP database is
> pretty far from 3rd normal form, but it's fast for the specific case
> of serving a webpage. If you start adding layers, you rapidly build a
> "correct" site, ... and which can be so slow as to be useless.
> 
> There's specific cases where tricks like this are useful, but I
> consider them to be just that: tricks. One-offs. Not necessarily a
> good base upon which to build a system. Honestly, sometimes it's
> better to just make a new database for your specific data instead of
> trying to shoehorn things into the WP data format. Depending on the
> data and the use case, of course. Most cases can be fit into custom
> post types and meta and taxonomies, without additional layers on top.
> Maybe not all cases, but in such cases it's worth asking if that data
> structure should live in the WP formats at all, or get its own custom
> tables.
> 
> -Otto
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers