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

[Otto]

On Wed, Jul 13, 2011 at 7:40 PM, Mike Schinkel
<mikeschinkel at newclarity.net> wrote:
> But it does require a lot of data maintenance effort on the part of the end-user, and when the end-users are not highly motivated to understand how to maintain the connections (i.e. when they are 9-to-5er employees or others who don't own the site) this approach falls down.  The non-motivated users shouldn't have to know to first add a taxonomy term and then add a related post and apply the same taxonomy term, especially when the term and the related post have a 1-to-1 correspondence.

Yes, but that isn't something end users should be doing. That's
something your code that implements this sort of data should be doing.

In other words, I'm not thinking of the end user ever seeing anything
I described. I was describing code and how the data is layed out, not
the user interface. If you were to implement such a thing, then you'd
show the user a list of cities, then they'd put in whatever was
needed, and you'd do the data and taxonomy and other crap behind the
scenes. They wouldn't create a term at all. They wouldn't create a
post, they'd put in the data and your code would create (or update)
the post, and apply the term to that post.

Stop thinking in terms of the User Interface. The user interface is up
to the person writing the code, how that code works behind the scenes
is entirely different.

> And while the data maintenance overhead might be acceptable for a website that showcase 5 major cites it would not work for sites where there there is a post for every city in the country because the data maintenance burden would be too great.

No greater than any other approach. How the taxonomies link locations
to their associated posts is entirely outside the realm of the
end-user.

> Yes, this linkage could be automated but you'll find when you start doing so it becomes overly cumbersome and complex

Creating a post is not complex. Creating a taxonomy is not complex.
Giving terms to posts is not complex. I see no complexity here
whatsoever. You create a new menu item, give the user a form, save the
data from that form. The hardest part is making the form for the user
to see, because user interfaces are tough.

> Shared Taxonomy Terms (6 JOINS)
> ...
> Shared Taxonomy Terms (4 JOINS)

If you're resorting to writing SQL, you're already making it fragile.
I know the traditional thinking is to only "get what you need" and to
make your queries specific. That system doesn't scale. Never has,
never will. The main problem is that there's less database servers in
the world than there are web servers. Treat the database as a data
store. Simple selects. As few joins as possible. The proper, scalable,
approach involves multiple queries. Performing two separate, but
highly fast and well indexed queries, will be faster than either one
of your query mechanisms, in the real world.

> If we want less complex then taxonomy meta is definitely the less complex of the two. And having a taxomomy meta would mean that we could add custom fields into the taxonomy edit screens and then that themes could assume it is any taxonomy meta is meta they might might want to be able to display.

You can already add custom fields to taxonomy edit screens, and store
the contents of those fields in associated CPTs. You don't need extra
tables to do that.

> In the case of associated posts I would then argue that we need a standard and performant approach to enable this so that the WordPress community will gravitate around the standard.  Maybe the addition of a 'post_id' field to wp_term_taxonomy?  Otherwise we just get a bunch of differently implemented hacks with no real ability for anyone to build on the work of others without bundling their plugin which itself is problematic.

Having multiple and different implementations is a *good thing*.
Letting people find the right way is a good thing. Having a fixed way
is a bad thing.

Your idea of a post_id field in the taxonomy, for example. What
happens when I want to associate two posts to a taxonomy? How does it
work with that?

Both one-to-one and one-to-many relationships are special cases of a
many-to-many relationship, and it's better, in the web world, for
relationships to be defined in the *code* instead of in the database
structure. There's more servers running code than there are databases.
Look at the sheer number of very large scale systems that have ditched
relational data completely in favor of simpler data stores. Facebook.
Twitter. Google. They all use simple data storage models and custom
"NoSQL" systems for a reason. Having your data logic in the code
scales much better than having your data be technically correct all
the time.

-Otto