0

テキスト列を含む大きな (数百 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グラブザエンチラーダ慣習に従い、サイトトラフィックがより効率的な2テーブルソリューションを要求するときに心配する必要があります?

4

2 に答える 2

1

特定のORMを使用していますか、それとも自家製のORMを使用していますか？Propelを使用している場合は、列を遅延ロードするように設定します。これにより、オブジェクトの残りの部分ではなく、明示的な要求に応じて列がロードされます。そうでない場合は、ORMがこれをサポートしているかどうかを確認するか、組み込みます。

于 2012-04-18T14:08:48.470 に答える
1

通常、時期尚早に最適化しないでください。

ただし、この場合は、これを行うための議論が既にあるため、ここで説明します。本文を表示せずに、記事のヘッダーのリストを表示している可能性があります。記事に関連付けられた独自のテーブル/クラスに本文を入れてみませんか?

記事のヘッダーと記事の本文は、すでに 2 つの別個のもののようです。

于 2012-04-18T13:56:13.450 に答える