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

Wed Jul 13 21:43:39 UTC 2011

I think that for almost all cases if we made a change there is 2 methods.

1. The term is linked to an (1 to 1) relationship object.
In this case if we added a column to the term that allowed us to link to a post id. Then add a postmeta to the term ID.

2. The second case is information similar to the description of the term and the original example of this thread that we could add a second column that could contan an aray that would add meta like image URLs etc. as this would only be used is a term is used it would not need to be searchable and would not need be a large load of needing an extra table.

--
Charles E. Frees-Melvin

Sent from my Rogers iPhone 3G

On 2011-07-13, at 18:33, Mike Schinkel <mikeschinkel at newclarity.net> wrote:

> 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
> 
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers