Question

对于是否要将包含文本列的大型（几百K记录）表分成2个表而言，有点困境。

有问题的表存储新闻文章：

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`)
)

所以，大事，在直接的SQL中，当你想获得头条新闻（最新消息）时，你会抓住你想要的列（id，label，dateCreated）并排除你不想要的那些（特别是膨胀的文本）列）

然而，在使用ORM时，会提取一个包含所有列的对象，因此抓取50篇最新文章会产生一些开销，或许不是很大，但是足以让我有点畏缩，因为在编写直接SQL时我永远不会抓住所有字段。

鉴于ORM现实，我应该将文本列分解为单独的相关表格，还是不要打扰，只需使用ORM抓住整个enchilada惯例，并在网站流量要求更高效时担心它， 2表解决方案？

Answer 1

通常情况下，我说不要过早优化。

然而，在这种情况下，我现在就把它分解出去，因为已经有了这样做的论据。您可能正在显示文章标题列表而不显示正文。为什么不将这些实体放在与文章相关的自己的表/类中呢？

似乎文章标题和文章正文已经是两个不同的东西了。

Answer 2

您使用的是特定的ORM还是本土的ORM？如果您正在使用Propel，请将列设置为延迟加载 - 然后它将在显式请求时加载，而不是与对象的其余部分一起加载。如果没有，那么看看你的ORM是否支持这个，或者将其构建。

MySQL大表与ORM后面的文本列

2 个答案: