Question

Having a bit of a dilemma over whether or not to break into 2 tables a large (few hundred K records) table that contains a text column.

The table in question stores news articles:

CREATE TABLE `article` (
  `id` mediumint(8) unsigned NOT NULL AUTO_INCREMENT,
  `articleType` varchar(7) DEFAULT NULL,
  `dateCreated` datetime NOT NULL,
  `label` varchar(75) NOT NULL,
  `lastUpdated` datetime NOT NULL,
  `reporter` mediumint(8) unsigned NOT NULL,
  `text` text NOT NULL
  PRIMARY KEY (`id`),
  KEY `reporter-fk` (`reporter`),
  CONSTRAINT `reporter-fk` FOREIGN KEY (`reporter`) REFERENCES `reporter` (`id`)
)

So, big deal, in straight SQL when you want to get the headlines (latest news) you would grab the columns you want (id, label, dateCreated) and exclude the ones you don’t want (particularly the bloated text column)

When working with an ORM, however, an object is fetched that contains all of the columns, so grabbing 50 of the most recent articles is going to incur some overhead, perhaps not hugely so, but enough to make me cringe a bit as I would never grab all fields in this case when writing straight SQL.

Given the ORM reality, should I break the text column out into a separate, related table, or not bother, just go with ORM grab-the-whole-enchilada convention and worry about it when site traffic demands the more efficient, 2 table solution?

Answer 1

Normally, I say don’t prematurely optimize.

However, in this case, I’d break it out now, as there is already an argument to do this. You probably are displaying a list of article headers without displaying the bodies. Why not put the bodies in their own table/class associated with the article?

It seems that an article header and an article body are already two separate things.