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?