Move comment fields to meta data instead

[Otto42]

Look at the comment table:

CREATE TABLE $wpdb->comments (
  comment_ID bigint(20) unsigned NOT NULL auto_increment,
  comment_post_ID bigint(20) unsigned NOT NULL default '0',
  comment_author tinytext NOT NULL,
  comment_author_email varchar(100) NOT NULL default '',
  comment_author_url varchar(200) NOT NULL default '',
  comment_author_IP varchar(100) NOT NULL default '',
  comment_date datetime NOT NULL default '0000-00-00 00:00:00',
  comment_date_gmt datetime NOT NULL default '0000-00-00 00:00:00',
  comment_content text NOT NULL,
  comment_karma int(11) NOT NULL default '0',
  comment_approved varchar(20) NOT NULL default '1',
  comment_agent varchar(255) NOT NULL default '',
  comment_type varchar(20) NOT NULL default '',
  comment_parent bigint(20) unsigned NOT NULL default '0',
  user_id bigint(20) unsigned NOT NULL default '0',
...

A lot of that is not actually being used on many sites and could be moved to standard meta data, available on demand, but not pulled out by default.

Specifically:

comment_author_IP - Used by Akismet and blacklist functions, included in emails sent to post authors/moderators, but once stored in the DB it's never really used again.

comment_karma - Used by some of the importers as a space to store temporary data. Not actually used by core for anything serious anywhere.

comment_agent - Used by Akismet and blacklist functions, but once stored in the DB it's never really used again.

These could be pushed to meta and thus still made available, but without them being in the main table.

This is a long term change, because some plugins would likely break. So the columns should be deprecated for a while first.

[shidouhikari]

comment_author_IP - I have a plugin that uses it to add country flags on author name

comment_agent - I've seen sites that parse user-agent to add browser and OS info, I just didn't add this to my plugin because it's too much theme related and plugin already has needed code to help any theme that would wanna do that (I just didn't implemented on my theme because I couldn't find best place for it :D )

comment_karma - I've read it was created to support a variety of voting features for comments and left unused by core so that plugins could use the field to implement their specific features, a field that remains unused so that plugins can use it without conflicting with other features' data - now that we have comment metadata it's pratically useless and plugins should create their own metadata tag for their features, remaining used only by legacy plugins (is there any really?)

The problem of those 2 is that they ARE storing data, so it would remain taking database space. If you don't want them just develop a plugin to delete them upon comment creating and anywhere they could be being edited. The extra load to query them as metadata when they are used doesn't justify the little and imperceptable performance gain we'd get when they aren't.

[nacin]

+1, but not sure how back compat we could remain...

[wonderboymusic]

comment_karma, when an index is added, is useful - moving to metadata would cause my ratings plugin to do a Meta_Query, which would make it slooooow - just sharing a use case