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

[Mike Schinkel]

On Jul 13, 2011, at 10:37 PM, Otto wrote:
> On Wed, Jul 13, 2011 at 7:40 PM, Mike Schinkel
> <mikeschinkel at newclarity.net> wrote:
> 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.

Although it is tangential to the discussion, a lot of users are doing that, if the sites I've seen built by site proprietors is any indication. But I digress.

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

That's good in theory. But in practice it gets complicated and fragile.  At least that's been my experience in coding and why I am moving away from the approach you propose.

Curious, have you implemented such a usage for a system with a large amount of data?

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

I'm not thinking about the UI at all. I don't think I said anything that would have implied that.

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

Again, we'll have to disagree. Not in the fine terms of "is creating a post complex?" but instead related to the approach you propose being an architecture best practice; I think it is not.

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

You ignored the fact (which I explicitly stated) that I was using SQL to indicate the related complexity of the data storage you proposed vs. taxonomy meta, not proposing the use of the SQL.  My guess is you scanned my email but missed that statement.

Doing it the way you state it is still complex data that needs to be maintained in sync and retrieved from the database, and doing it as you propose is still more complex than a taxonomy meta would be, no matter how you slice it.

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

Yes is it possible, but we disagree on what should be a best practice.

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

Letting people find the right way is a good thing. Before a pattern emerges. 

But after a pattern emerges "choice" just creates needless chaos.  If every website owner got to choose his own protocol (vs. be offered HTTP as a best practice) then we'd not have the web we have today.

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

Depends. What percentage of use-cases need two?  If 7% need two and 93% need one then supporting the 93% use-case makes sense and then let the 7% use-case figure out an alternative.  (BTW, I do not know if it is 7% & 93% or 40% and 60%, but the point is that common use-cases are a pattern worth addressing.)

And if there is a common need for two then address it differently.  But not addressing it doesn't help those with either set of needs.

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

I thought WordPress tackled the 80% use-case in WordPress and left the 20% use-case to plugins?  Are you saying that more than 20% of WordPress sites need to scale like Facebook, Twitter and Google?  I'm sure that's not what you meant.  Taxonomy meta would address issues that many sites have, and almost none of them need to scale beyond what it could support.  For others there is Memcached, nginx, etc.

The irony is you are proposing that you put data into the database too, only you are proposing it in a more complex way using existing structures vs. in a simpler way using additional structures.  Taxonomy meta *is* name-value pairs, it's not a relationally correct model either so the reference to "NoSQL" in this context is a non-sequiter.

Anyway, this is going nowhere.  As usual on these subjects. :)

-Mike