[wp-trac] Re: [WordPress Trac] #3723: Tagging
WordPress Trac
wp-trac at lists.automattic.com
Wed Jan 31 09:05:02 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 majelbstoat):
I would say that using Christine's schema validates her good design - and
it is a good design, fully normalised for many to many relationships. We
shouldn't not use it, just because it's been used already. If tagging
plugins aren't going away, whatever we call the new table, aren't UTW and
others going to have to use it anyway? Rather than saying UTW has to make
code alterations to use a new table name, couldn't we just make WordPress
use what's there already? Anyway, the name's not a major point - just
trying to think about how this can be implemented so that the least number
of things need to be re-engineered about it. You're probably right about
unexpected results though... Maybe Christine, Jerome et al could be
approached for some comments as they have quite a stake in this?
Having said all that, the schema Ryan proposed will do the job well. Do
we need a tag_count column though? "SELECT COUNT(*) FROM $wpdb->tags
WHERE tag_id = 'xx'" would do the job and doesn't risk the count getting
out of sync. 'tag' is for the human readable, 'rawtag' for internal use,
is that right? How come they're different sizes? Is rawtag going to be
unique, or are we allowing 'London', 'london' and 'LONDON' as separate
tags?
I like the synonym_of idea - again, not imperative, but helpful
nonetheless.
--
Ticket URL: <http://trac.wordpress.org/ticket/3723#comment:10>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list