Grab a seat. On Delaying 2.2, separating tables

[Robert Deaton]

Okay, I'll try to cut right to the point here, cause its getting late
and my brain functionality is quickly slipping away. WordPress 2.2 is
shipped for release very shortly. Unfortunately, we're cutting it
pretty close again, with big changes going in only a week before its
scheduled for final release. Not only does this mean we're once again
not leaving time for the testing that is likely needed (think WP 2.0),
it means we are only a week away from releasing into the wild what I
see to be a mistake.

WordPress 2.2 features the new WP core tagging system. That's an
inevitability, its not going anywhere, and that's not what I'm
suggesting. The problem is, like linkcategories, its been thrown into
the categories table as well. Now, without getting into specifics, it
is a given that tags and categories are not the same. So why are we
storing them in the same table? Post categories and link categories
are also not the same, so again, why?

I believe that we should take the time now, before a release of
WordPress is made with these database schema changes, to fix the
issue. I think that the categories table needs to be resplit into a
link categories table, a post categories table, and a tag table, each
set up to handle their own specific job instead of throwing them
together with legacy fields. Let's have a look at the categories
table.

13 $wp_queries="CREATE TABLE $wpdb->categories (
14  cat_ID bigint(20) NOT NULL auto_increment,

15  cat_name varchar(55) NOT NULL default '',
16  category_nicename varchar(200) NOT NULL default '',
^^ those two lines do seem rather inconsistent, don't you think?

17  category_description longtext NOT NULL,
18  category_parent bigint(20) NOT NULL default '0',
19  category_count bigint(20) NOT NULL default '0',

20  link_count bigint(20) NOT NULL default '0',
21  tag_count bigint(20) NOT NULL default '0',
^^ two different count fields only used for some of the things stored
in the table at different times

22  posts_private tinyint(1) NOT NULL default '0',
23  links_private tinyint(1) NOT NULL default '0',
^^ again

24  type tinyint NOT NULL default '1',
^^ a bitfield, instead of an enum? brilliant.

25  PRIMARY KEY  (cat_ID),
26  KEY category_nicename (category_nicename)
27 ) $charset_collate;

So, basically, its all lumped together. No wonder WP is notorious for
slow and poor queries.

While on the subject of splitting these out, I also believe that it is
about time that we created a proper schema and structure for managing
category hierarchies. I'm personally favoring the nested set model at
the moment, but really any proper schema that would allow us to manage
hierarchies easily with fewer queries would do.

The categories schema changes can probably wait for the next version,
as its a large undertaking and a lot to test, however I think that it
definitely wouldn't hurt to push back 2.2 and get these tables
separated and sorted out before they ship in a release and then we
have to worry about serious backwards compatibility issues when trying
to make these changes in the next version.

--
--Robert Deaton
http://lushlab.com
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Computer Guru]

+1

The UTW import script is BROKEN and imports "Multiple Word Tags" as "Multiple-Word-Tags" - but that's not the point.

Robert, you're 100% correct. The current layout made my heart skip a beat when I saw that the tags weren't in wp_tags as they were in UTW but in wp_categories... and that we were using the category_type to ID a tag.

Reasons why tags shouldn't be with categories:

1) Tags aren't hierarchal
2) Tags can (theoretically - again, look at UTW) have synonyms -- Categories shouldn't.
3) Tags and categories aren't dependant on one-another, so there is absolutely no benefit to sticking them in the same table. Again, *TABLES ARE CHEAP* database clutter, however, isn't.


Computer Guru
NeoSmart Technologies
http://neosmart.net/blog/

> -----Original Message-----
> From: wp-hackers-bounces@... [mailto:wp-hackers-
> bounces@...] On Behalf Of Robert Deaton
> Sent: Sunday, April 15, 2007 9:06 AM
> To: wp-hackers@...
> Subject: [wp-hackers] Grab a seat. On Delaying 2.2, separating tables
>
> Okay, I'll try to cut right to the point here, cause its getting late
> and my brain functionality is quickly slipping away. WordPress 2.2 is
> shipped for release very shortly. Unfortunately, we're cutting it
> pretty close again, with big changes going in only a week before its
> scheduled for final release. Not only does this mean we're once again
> not leaving time for the testing that is likely needed (think WP 2.0),
> it means we are only a week away from releasing into the wild what I
> see to be a mistake.
>
> WordPress 2.2 features the new WP core tagging system. That's an
> inevitability, its not going anywhere, and that's not what I'm
> suggesting. The problem is, like linkcategories, its been thrown into
> the categories table as well. Now, without getting into specifics, it
> is a given that tags and categories are not the same. So why are we
> storing them in the same table? Post categories and link categories
> are also not the same, so again, why?
>
> I believe that we should take the time now, before a release of
> WordPress is made with these database schema changes, to fix the
> issue. I think that the categories table needs to be resplit into a
> link categories table, a post categories table, and a tag table, each
> set up to handle their own specific job instead of throwing them
> together with legacy fields. Let's have a look at the categories
> table.
>
> 13 $wp_queries="CREATE TABLE $wpdb->categories (
> 14  cat_ID bigint(20) NOT NULL auto_increment,
>
> 15  cat_name varchar(55) NOT NULL default '',
> 16  category_nicename varchar(200) NOT NULL default '',
> ^^ those two lines do seem rather inconsistent, don't you think?
>
> 17  category_description longtext NOT NULL,
> 18  category_parent bigint(20) NOT NULL default '0',
> 19  category_count bigint(20) NOT NULL default '0',
>
> 20  link_count bigint(20) NOT NULL default '0',
> 21  tag_count bigint(20) NOT NULL default '0',
> ^^ two different count fields only used for some of the things stored
> in the table at different times
>
> 22  posts_private tinyint(1) NOT NULL default '0',
> 23  links_private tinyint(1) NOT NULL default '0',
> ^^ again
>
> 24  type tinyint NOT NULL default '1',
> ^^ a bitfield, instead of an enum? brilliant.
>
> 25  PRIMARY KEY  (cat_ID),
> 26  KEY category_nicename (category_nicename)
> 27 ) $charset_collate;
>
> So, basically, its all lumped together. No wonder WP is notorious for
> slow and poor queries.
>
> While on the subject of splitting these out, I also believe that it is
> about time that we created a proper schema and structure for managing
> category hierarchies. I'm personally favoring the nested set model at
> the moment, but really any proper schema that would allow us to manage
> hierarchies easily with fewer queries would do.
>
> The categories schema changes can probably wait for the next version,
> as its a large undertaking and a lot to test, however I think that it
> definitely wouldn't hurt to push back 2.2 and get these tables
> separated and sorted out before they ship in a release and then we
> have to worry about serious backwards compatibility issues when trying
> to make these changes in the next version.
>
> --
> --Robert Deaton
> http://lushlab.com
> _______________________________________________
> wp-hackers mailing list
> wp-hackers@...
> http://lists.automattic.com/mailman/listinfo/wp-hackers

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Jamie Talbot]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Deaton wrote:
> I believe that we should take the time now, before a release of
> WordPress is made with these database schema changes, to fix the
> issue. I think that the categories table needs to be resplit into a
> link categories table, a post categories table, and a tag table, each
> set up to handle their own specific job instead of throwing them
> together with legacy fields.

I'm strongly in favour of your idea Robert and am on the record as being strong against the current
implementation.  I believe the schema we have now will damage WordPress' credibility among
developers.  In my eyes it's a very poor design choice.  It doesn't matter that the end user doesn't
know the difference - those who come into contact with the codebase will.

The issues with the structure now in use were debated strongly on trac[1], but unfortunately Matt
went and committed the changes anyway, without ever really addressing them.  Comments from ryan[2]
and rob1n[3] seem to suggest they also have their doubts.  In fact, I haven't seen one comment from
anyone who is in favour of this monolithic design.  It seems like a unilateral decision, the main
argument for which was "We already have API that we can reuse" - never mind the huge amount of
changes that have since had to be made anyway.  With the addition of the bitfield, we now have
another horrendous hack to go along with 'link_count > 0'.

Unfortunately, I suspect that all of this will be dismissed with "It's there and it works, so why
bother changing it" and "We have a public deadline, we should stick to it".  Neither of these
arguments hold water.

Jamie.

[1] http://trac.wordpress.org/ticket/3723 (my comments as 'majelbstoat')
[2] http://trac.wordpress.org/ticket/3723#comment:42
[3] http://trac.wordpress.org/ticket/4148#comment:2 (at the bottom)

- --
http://jamietalbot.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGIcZzrovxfShShFARAh/3AKCESjE187LCUCmgh7dZVWb0OW9vkQCfd5lZ
tLu2Hfcyc+t3BpUFIXP4qrQ=
=nubO
-----END PGP SIGNATURE-----
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Mark Jaquith]

On Apr 15, 2007, at 2:05 AM, Robert Deaton wrote:

> The categories schema changes can probably wait for the next version,
> as its a large undertaking and a lot to test, however I think that it
> definitely wouldn't hurt to push back 2.2 and get these tables
> separated and sorted out before they ship in a release and then we
> have to worry about serious backwards compatibility issues when trying
> to make these changes in the next version.

It certainly wouldn't hurt my feelings.  It was supposed to be a 4  
month development cycle anyway, and it was a mistake that it was  
scheduled for April.

And I'm definitely off the fence with regards to our taxonomy  
implementation.  This is madness.  Number of tables is a meaningless  
metric.  Community consensus, reduction of coding headaches, and KISS  
design are important metrics.  Split 'em, and do it properly.  If not  
now, immediately after 2.2

--
Mark Jaquith
http://markjaquith.com/

Covered Web Services
http://coveredwebservices.com/


_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Elliotte Harold]

+1
--
Elliotte Rusty Harold  elharo@...
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Peter Westwood]

Robert Deaton wrote:

> Okay, I'll try to cut right to the point here, cause its getting late
> and my brain functionality is quickly slipping away. WordPress 2.2 is
> shipped for release very shortly. Unfortunately, we're cutting it
> pretty close again, with big changes going in only a week before its
> scheduled for final release. Not only does this mean we're once again
> not leaving time for the testing that is likely needed (think WP 2.0),
> it means we are only a week away from releasing into the wild what I
> see to be a mistake.
>
> WordPress 2.2 features the new WP core tagging system. That's an
> inevitability, its not going anywhere, and that's not what I'm
> suggesting. The problem is, like linkcategories, its been thrown into
> the categories table as well. Now, without getting into specifics, it
> is a given that tags and categories are not the same. So why are we
> storing them in the same table? Post categories and link categories
> are also not the same, so again, why?
>

+1

I really can't see anyone justifying releasing 2.2 any time soon anyway.

The original idea behind the 120day release cycle was for a decent
beta/stability period before release [1]:

"
2 months of crazy fun wild development where anything goes
1 month of polishing things a little bit, and performance
Feature freeze.
1 month of testing, with a public beta release at the beginning
"

For me with regard to the current tagging changes it feels like 2.2 is
still in the first phase.

If we wanted to keep to the schedule for 2.2 then the tagging changes
should have waiting till 2.3!

[1] http://comox.textdrive.com/pipermail/wp-hackers/2006-October/008907.html

westi
--
Peter Westwood
http://blog.ftwr.co.uk
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Pixline › Paolo Tresso]

15/apr/07, Robert Deaton:
> I believe that we should take the time now, before a release of
> WordPress is made with these database schema changes, to fix the
> issue. I think that the categories table needs to be resplit into a
> link categories table, a post categories table, and a tag table, each
> set up to handle their own specific job instead of throwing them
> together with legacy fields.

a big and heavy +1 for me.  I'm really concerned about tags and db,  
now that I've understood what didn't sound to me.

if 2.2 gets out with this db structure, it will be official; think  
about the number of plugins and themes that will work on it,  and  
count how many headaches will face wp-core team about backward  
compatibility... Taking time and split tables will allow some authors  
to write their plugins and be ready for 2.2

And the beautifulness of open source is even to have a real  
explaination about delays :-)

Paolo
------------------------------------
Pixline Freelance Network
http://pixline.net



_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[spencerp]

Pixline wrote:

> 15/apr/07, Robert Deaton:
>> I believe that we should take the time now, before a release of
>> WordPress is made with these database schema changes, to fix the
>> issue. I think that the categories table needs to be resplit into a
>> link categories table, a post categories table, and a tag table, each
>> set up to handle their own specific job instead of throwing them
>> together with legacy fields.
>
> a big and heavy +1 for me.  I'm really concerned about tags and db,
> now that I've understood what didn't sound to me.
>
> if 2.2 gets out with this db structure, it will be official; think
> about the number of plugins and themes that will work on it,  and
> count how many headaches will face wp-core team about backward
> compatibility... Taking time and split tables will allow some authors
> to write their plugins and be ready for 2.2
>
> And the beautifulness of open source is even to have a real
> explaination about delays :-)
>
> Paolo

I agree, +1 from me... ;) :)

spencerp
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Dion Hulse (dd32)]

On Sun, 15 Apr 2007 20:52:19 +1000, Pixline <supporto@...> wrote:
> if 2.2 gets out with this db structure, it will be official; think about  
> the number of plugins and themes that will work on it,  and count how  
> many headaches will face wp-core team about backward compatibility...  
> Taking time and split tables will allow some authors to write their  
> plugins and be ready for 2.2

another +1 from me,
Once its released, theres going to be a lot of new plugins centered around  
it, It seems tag support has come late in the dev. cycle, i was supprised  
to see more tagging patches coming in after the version was bumped(to  
almost-beta).
I think its in the interest both of future WP development, and for the  
Plugin authors to get the tagging support done well in a flexible manner,  
if that means breaking up the category table into 3 seperate tables, then  
so be it.. But it needs to be done well first, it'll be harder to change  
it down the line.
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Andy Staines]

For what it's worth I'll cast my vote in favour. Getting rid of the link
categories table was itself bad database design and adding tags just
compounds that. It's no way to treat a relational database!

Andy

>
> another +1 from me,
> Once its released, theres going to be a lot of new plugins centered around
> it, It seems tag support has come late in the dev. cycle, i was supprised
> to see more tagging patches coming in after the version was bumped(to
> almost-beta).
> I think its in the interest both of future WP development, and for the
> Plugin authors to get the tagging support done well in a flexible manner,
> if that means breaking up the category table into 3 seperate tables, then
> so be it.. But it needs to be done well first, it'll be harder to change
> it down the line.

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Knut-Olav Hoven]

On Sunday 15 April 2007 08:05:30 Robert Deaton wrote:
> I believe that we should take the time now, before a release of
> WordPress is made with these database schema changes, to fix the
> issue. I think that the categories table needs to be resplit into a
> link categories table, a post categories table, and a tag table, each
> set up to handle their own specific job instead of throwing them
> together with legacy fields. Let's have a look at the categories
> table.
+1
I agree. The categories table is getting bloated with columns only needed
depending on the context (tag, category, link). This not only makes the table
large, but harder to maintain and a pain to handle in the mysql console.

> 24  type tinyint NOT NULL default '1',
> ^^ a bitfield, instead of an enum? brilliant.
Enums are mysql specific and would make it harder to port WordPress to another
database in some rare future.
But you are partially right pointing at this column as an issue. It is
impossible to see what this field does by just lookin at the database schema.
It is clearly some sort of filtering, but that's that.


On Sunday 15 April 2007 08:30:12 Jamie Talbot wrote:
> The issues with the structure now in use were debated strongly on trac[1],
> but unfortunately Matt went and committed the changes anyway, without ever
> really addressing them.  Comments from ryan[2] and rob1n[3] seem to suggest
> they also have their doubts.  In fact, I haven't seen one comment from
> anyone who is in favour of this monolithic design.  It seems like a
> unilateral decision, the main argument for which was "We already have API
> that we can reuse" - never mind the huge amount of changes that have since
> had to be made anyway.  With the addition of the bitfield, we now have
> another horrendous hack to go along with 'link_count > 0'.
It looks like this decission was made in a hurry just to make the schedule. If
the API can not easily be altered to use multiple tables it is probably not a
very good API at all.

There are some similarities between post_categories, link_categories and tags,
but not more than it is between anything else in WordPress: common ID, name,
nicename and description/content.

Then maybe tags should be rescheduled to 2.3.


--
Knut-Olav Hoven
Systemutvikler               mob: [phone]
Linpro AS                    http://www.linpro.no/
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Ryan Boren]

On 4/14/07, Robert Deaton <false.hopes@...> wrote:
> The categories schema changes can probably wait for the next version,
> as its a large undertaking and a lot to test, however I think that it
> definitely wouldn't hurt to push back 2.2 and get these tables
> separated and sorted out before they ship in a release and then we
> have to worry about serious backwards compatibility issues when trying
> to make these changes in the next version.

No argument from me.

Ryan
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Robin Adrianse-2]

+1. Definitely +1.

On 4/14/07, Robert Deaton <false.hopes@...> wrote:

>
> Okay, I'll try to cut right to the point here, cause its getting late
> and my brain functionality is quickly slipping away. WordPress 2.2 is
> shipped for release very shortly. Unfortunately, we're cutting it
> pretty close again, with big changes going in only a week before its
> scheduled for final release. Not only does this mean we're once again
> not leaving time for the testing that is likely needed (think WP 2.0),
> it means we are only a week away from releasing into the wild what I
> see to be a mistake.
>
> WordPress 2.2 features the new WP core tagging system. That's an
> inevitability, its not going anywhere, and that's not what I'm
> suggesting. The problem is, like linkcategories, its been thrown into
> the categories table as well. Now, without getting into specifics, it
> is a given that tags and categories are not the same. So why are we
> storing them in the same table? Post categories and link categories
> are also not the same, so again, why?
>
> I believe that we should take the time now, before a release of
> WordPress is made with these database schema changes, to fix the
> issue. I think that the categories table needs to be resplit into a
> link categories table, a post categories table, and a tag table, each
> set up to handle their own specific job instead of throwing them
> together with legacy fields. Let's have a look at the categories
> table.
>
> 13      $wp_queries="CREATE TABLE $wpdb->categories (
> 14        cat_ID bigint(20) NOT NULL auto_increment,
>
> 15        cat_name varchar(55) NOT NULL default '',
> 16        category_nicename varchar(200) NOT NULL default '',
> ^^ those two lines do seem rather inconsistent, don't you think?
>
> 17        category_description longtext NOT NULL,
> 18        category_parent bigint(20) NOT NULL default '0',
> 19        category_count bigint(20) NOT NULL default '0',
>
> 20        link_count bigint(20) NOT NULL default '0',
> 21        tag_count bigint(20) NOT NULL default '0',
> ^^ two different count fields only used for some of the things stored
> in the table at different times
>
> 22        posts_private tinyint(1) NOT NULL default '0',
> 23        links_private tinyint(1) NOT NULL default '0',
> ^^ again
>
> 24        type tinyint NOT NULL default '1',
> ^^ a bitfield, instead of an enum? brilliant.
>
> 25        PRIMARY KEY  (cat_ID),
> 26        KEY category_nicename (category_nicename)
> 27      ) $charset_collate;
>
> So, basically, its all lumped together. No wonder WP is notorious for
> slow and poor queries.
>
> While on the subject of splitting these out, I also believe that it is
> about time that we created a proper schema and structure for managing
> category hierarchies. I'm personally favoring the nested set model at
> the moment, but really any proper schema that would allow us to manage
> hierarchies easily with fewer queries would do.
>
> The categories schema changes can probably wait for the next version,
> as its a large undertaking and a lot to test, however I think that it
> definitely wouldn't hurt to push back 2.2 and get these tables
> separated and sorted out before they ship in a release and then we
> have to worry about serious backwards compatibility issues when trying
> to make these changes in the next version.
>
> --
> --Robert Deaton
> http://lushlab.com
> _______________________________________________
> wp-hackers mailing list
> wp-hackers@...
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Brian Layman]

> For what it's worth I'll cast my vote in favour. Getting rid of the
link categories table was itself bad
> database design and adding tags just compounds that. It's no way to
treat a relational database!

I've not looked at the tagging implementation, but I will +1 categories
(re)split.  I never saw the bang for the buck of unifying these two
tables and while conversions weren't quite as bad as I predicted them to
be (on this list), we still lost features and broke parts of sites (link
categories suddenly appearing that were hidden before, missing blog roll
side bar sections, and other oddities.).  I can't imagine adding tags to
the same table will be a path to future success.  That table is going to
need to be split again at some point.  These are not all uniform
concepts.  Let's do it now before we get further down the path.

Thanks for bringing this up again Robert.

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Matt Freedman]

+0.5

I think that Tags should have it's own table, but Link Categories and Post
Categories *should* be in the same table, simply because most people
probably won't have very many Link Cats, so you'll end up with a Table with
like less than 10 rows in it.


On 4/15/07, Brian Layman <Brian@...> wrote:

>
> > For what it's worth I'll cast my vote in favour. Getting rid of the
> link categories table was itself bad
> > database design and adding tags just compounds that. It's no way to
> treat a relational database!
>
> I've not looked at the tagging implementation, but I will +1 categories
> (re)split.  I never saw the bang for the buck of unifying these two
> tables and while conversions weren't quite as bad as I predicted them to
> be (on this list), we still lost features and broke parts of sites (link
> categories suddenly appearing that were hidden before, missing blog roll
> side bar sections, and other oddities.).  I can't imagine adding tags to
> the same table will be a path to future success.  That table is going to
> need to be split again at some point.  These are not all uniform
> concepts.  Let's do it now before we get further down the path.
>
> Thanks for bringing this up again Robert.
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers@...
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>

--
Matt (speedboxer@...)
http://mattsblog.ca/
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Computer Guru]

I agree with your deduction there, but I disagree with regards to proper programming procedure.

DB optimization doesn't make a difference how many entries there are in the table... If it was 1 or 1000, the query complexity and db-clutter will not be changed.....

Computer Guru
NeoSmart Technologies
http://neosmart.net/blog/

> -----Original Message-----
> From: wp-hackers-bounces@... [mailto:wp-hackers-
> bounces@...] On Behalf Of Matt
> Sent: Sunday, April 15, 2007 10:48 PM
> To: wp-hackers@...
> Subject: Re: [wp-hackers] Grab a seat. On Delaying 2.2, separating
> tables
>
> +0.5
>
> I think that Tags should have it's own table, but Link Categories and
> Post
> Categories *should* be in the same table, simply because most people
> probably won't have very many Link Cats, so you'll end up with a Table
> with
> like less than 10 rows in it.
>
>
> On 4/15/07, Brian Layman <Brian@...> wrote:
> >
> > > For what it's worth I'll cast my vote in favour. Getting rid of the
> > link categories table was itself bad
> > > database design and adding tags just compounds that. It's no way to
> > treat a relational database!
> >
> > I've not looked at the tagging implementation, but I will +1
> categories
> > (re)split.  I never saw the bang for the buck of unifying these two
> > tables and while conversions weren't quite as bad as I predicted them
> to
> > be (on this list), we still lost features and broke parts of sites
> (link
> > categories suddenly appearing that were hidden before, missing blog
> roll
> > side bar sections, and other oddities.).  I can't imagine adding tags
> to
> > the same table will be a path to future success.  That table is going
> to
> > need to be split again at some point.  These are not all uniform
> > concepts.  Let's do it now before we get further down the path.
> >
> > Thanks for bringing this up again Robert.
> >
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers@...
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> >
>
>
>
> --
> Matt (speedboxer@...)
> http://mattsblog.ca/
> _______________________________________________
> wp-hackers mailing list
> wp-hackers@...
> http://lists.automattic.com/mailman/listinfo/wp-hackers

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Chris-212]

I'll add my view - don't do this!!
The categories table is for categories - if "other purposed" information
is thrown in there, it's _all_ bad news
New information should go into new tables. Tagging should be in new
table - they can be linked as required in the sql queries.
This keeps table bloat down, makes for more transparency, easier bug
chasing and more understandable code - all of which eases support and
development.

An most importantly of all, reduces the liklihood that existing blogs
and plugins will be badly impacted.

SQL is a fine language for extracting related information from related
tables - and provides designer control.
More tables, less in each, with good indexing, makes for happy people! I
already see fields in tables that are not used (e.g. wp-posts)
This idea seems like a major change to a product that has many 1000 of
users, and 100 of plugins. I have not read any good reason for these
changes in this thread so far.
As a developer looking at Wordpress, my personal preference would be to
keep it stable, reduce the number of changes, and improve the
documentation which quite frankly, would benefit more people - try
looking for descriptions of all the functions etc-  I have not found it
easy, as many are either "waiting" for 2.1, or searches produce answers
for v1.5 which I am reluctant to trust - so I need to read and
understand the actual code, which is a lot slower.

(P.S. I don't pretend to have a long history with WP, but I do have 20
years experience of database design, and a few years of php MySQL)

Cheers
Chris


Robin Adrianse wrote:

> +1. Definitely +1.
>
> On 4/14/07, Robert Deaton <false.hopes@...> wrote:
>>
>> Okay, I'll try to cut right to the point here, cause its getting late
>> and my brain functionality is quickly slipping away. WordPress 2.2 is
>> shipped for release very shortly. Unfortunately, we're cutting it
>> pretty close again, with big changes going in only a week before its
>> scheduled for final release. Not only does this mean we're once again
>> not leaving time for the testing that is likely needed (think WP 2.0),
>> it means we are only a week away from releasing into the wild what I
>> see to be a mistake.
>>
>> WordPress 2.2 features the new WP core tagging system. That's an
>> inevitability, its not going anywhere, and that's not what I'm
>> suggesting. The problem is, like linkcategories, its been thrown into
>> the categories table as well. Now, without getting into specifics, it
>> is a given that tags and categories are not the same. So why are we
>> storing them in the same table? Post categories and link categories
>> are also not the same, so again, why?
>>
>> I believe that we should take the time now, before a release of
>> WordPress is made with these database schema changes, to fix the
>> issue. I think that the categories table needs to be resplit into a
>> link categories table, a post categories table, and a tag table, each
>> set up to handle their own specific job instead of throwing them
>> together with legacy fields. Let's have a look at the categories
>> table.
>>
>> 13      $wp_queries="CREATE TABLE $wpdb->categories (
>> 14        cat_ID bigint(20) NOT NULL auto_increment,
>>
>> 15        cat_name varchar(55) NOT NULL default '',
>> 16        category_nicename varchar(200) NOT NULL default '',
>> ^^ those two lines do seem rather inconsistent, don't you think?
>>
>> 17        category_description longtext NOT NULL,
>> 18        category_parent bigint(20) NOT NULL default '0',
>> 19        category_count bigint(20) NOT NULL default '0',
>>
>> 20        link_count bigint(20) NOT NULL default '0',
>> 21        tag_count bigint(20) NOT NULL default '0',
>> ^^ two different count fields only used for some of the things stored
>> in the table at different times
>>
>> 22        posts_private tinyint(1) NOT NULL default '0',
>> 23        links_private tinyint(1) NOT NULL default '0',
>> ^^ again
>>
>> 24        type tinyint NOT NULL default '1',
>> ^^ a bitfield, instead of an enum? brilliant.
>>
>> 25        PRIMARY KEY  (cat_ID),
>> 26        KEY category_nicename (category_nicename)
>> 27      ) $charset_collate;
>>
>> So, basically, its all lumped together. No wonder WP is notorious for
>> slow and poor queries.
>>
>> While on the subject of splitting these out, I also believe that it is
>> about time that we created a proper schema and structure for managing
>> category hierarchies. I'm personally favoring the nested set model at
>> the moment, but really any proper schema that would allow us to manage
>> hierarchies easily with fewer queries would do.
>>
>> The categories schema changes can probably wait for the next version,
>> as its a large undertaking and a lot to test, however I think that it
>> definitely wouldn't hurt to push back 2.2 and get these tables
>> separated and sorted out before they ship in a release and then we
>> have to worry about serious backwards compatibility issues when trying
>> to make these changes in the next version.
>>
>> --
>> --Robert Deaton
>> http://lushlab.com
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers@...
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers@...
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
>

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Robin Adrianse-2]

I don't agree. One of my big, BIG pet peeves of the 2.1 release was that
link and post categories were, so to speak, "unified." If we're going to
separate them in the UI, then we should really put them in separate tables.

On 4/15/07, Matt <speedboxer@...> wrote:

>
> +0.5
>
> I think that Tags should have it's own table, but Link Categories and Post
> Categories *should* be in the same table, simply because most people
> probably won't have very many Link Cats, so you'll end up with a Table
> with
> like less than 10 rows in it.
>
>
> On 4/15/07, Brian Layman <Brian@...> wrote:
> >
> > > For what it's worth I'll cast my vote in favour. Getting rid of the
> > link categories table was itself bad
> > > database design and adding tags just compounds that. It's no way to
> > treat a relational database!
> >
> > I've not looked at the tagging implementation, but I will +1 categories
> > (re)split.  I never saw the bang for the buck of unifying these two
> > tables and while conversions weren't quite as bad as I predicted them to
> > be (on this list), we still lost features and broke parts of sites (link
> > categories suddenly appearing that were hidden before, missing blog roll
> > side bar sections, and other oddities.).  I can't imagine adding tags to
> > the same table will be a path to future success.  That table is going to
> > need to be split again at some point.  These are not all uniform
> > concepts.  Let's do it now before we get further down the path.
> >
> > Thanks for bringing this up again Robert.
> >
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers@...
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> >
>
>
>
> --
> Matt (speedboxer@...)
> http://mattsblog.ca/
> _______________________________________________
> wp-hackers mailing list
> wp-hackers@...
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Matt Mullenweg]

Robin Adrianse wrote:
> I don't agree. One of my big, BIG pet peeves of the 2.1 release was that
> link and post categories were, so to speak, "unified." If we're going to
> separate them in the UI, then we should really put them in separate tables.

By that argument we should have separate tables for posts, pages,
uploads, rss feeds, rewrite rules...

For April Fool's next year we should do a version with 1 post per table.
Why?

* Posts are used differently in different contexts.
* You can do custom fields with ACTUAL fields.
* Get the benefit of the per-table query cache.
* "Tables are cheap!"

--
Matt Mullenweg
  http://photomatt.net | http://wordpress.org
http://automattic.com | http://akismet.com
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Elliotte Harold]

Matt Mullenweg wrote:

> By that argument we should have separate tables for posts, pages,
> uploads, rss feeds, rewrite rules...
>

Posts, pages, uploads, and rewrite rules should be separate tables.

Theoretically RSS feeds shouldn't be because they're dependent on the
post table. Sometimes optimization requires that sort of denormalization
though, but I don't cross that bridge until i come to it.

--
Elliotte Rusty Harold  elharo@...
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers