[wp-hackers] Grab a seat. On Delaying 2.2, separating tables

[Chris]

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 at gmail.com> 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 at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
>