[wp-trac] Re: [WordPress Trac] #3723: Tagging
WordPress Trac
wp-trac at lists.automattic.com
Fri Mar 30 19:50:25 GMT 2007
#3723: Tagging
-------------------------+--------------------------------------------------
Reporter: ryan | Owner: ryan
Type: enhancement | Status: new
Priority: normal | Milestone: 2.2
Component: General | Version: 2.1
Severity: normal | Resolution:
Keywords: tags |
-------------------------+--------------------------------------------------
Comment (by Otto42):
Replying to [comment:54 ryan]:
> Perhaps we could add a type bitfield to the categories table so that we
can avoid some of the gymnastics with the counts. If a category object is
marked as a category in the type field, it would be displayed in the
manage cats list. If a category belongs to no posts or links, it would
still be listed until it is deleted via Manage Cats. Deleting would
consist of masking out the category bits in the type bitfield or
completely deleting if the bitfield is empty.
What do these crazy gymnastics gain you though? I mean, you've got a list
of words here which can be categories or tags. So you put in a flag to say
which they are, or maybe they can be both. Fine. Brilliant. But how is
this any better than two tables: one for tags, and one for categories? I
mean, you've got one table with a flag to say whether an entry is on one
side of the fence or the other (or both). It's just really, really silly
and violates virtually all relational database principles.
Sure, you can treat categories as tags if you like. Yes, a lot of services
do that. But that's a nasty hack to begin with, and the only reason they
do that is that tags were not in the Wordpress core when they started
looking for them. If you're adding tags to the core, then treating
categories as tags should be *removed*. Categories should not have
rel="tag" on them, IMO. They are not tags. Which is sorta my whole point,
I guess.
Now, I would support eliminating categories entirely in favor of tags (as
tags are more useful, IMO), but you're right, the outcry would be
tremendous. But this half-way solution is worse than any possible
alternative as I see it. It over complicates things for absolutely no
benefit.
>Either consulting or ignoring the type bitfield would yield a separated
or merged taxonomy, as desired.
SQL has this nifty thing called a JOIN. Depending on what tables you
joined, you could get a separated or merged taxonomy, as desired. ;)
--
Ticket URL: <http://trac.wordpress.org/ticket/3723#comment:55>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list