私のアプリケーションには、トピックへの応答の表があります。構造はおおよそ次のとおりです。
CREATE TABLE responses (
id INT NOT NULL PRIMARY KEY,
topic_id INT NOT NULL,
author_id INT NOT NULL,
response TEXT
);
id
は自動インクリメント フィールドでtopic_id
ありauthor_id
、外部キーであり、適切なインデックスなどがあります。
私は常に挿入時間、通常は最新の順に並べたいと思っています。ほとんどの場合、 でフィルタリングしtopic_id
ます。典型的なクエリは次のようになります。
SELECT * FROM responses WHERE topic_id=123 ORDER BY id DESC LIMIT 20;
-- or, for pagination:
SELECT * FROM responses WHERE topic_id=123 AND id < 456789 ORDER BY id DESC LIMIT 20;
ブロックリストを実装したい - 各ユーザーには、author_id
見たくない のリストがあります。上位 20 件の結果を取得する必要があります。これらauthor_id
のとそれらに返信する応答は除外されます。
行を除外する必要があるかどうかを判断するのは非常に複雑です。データベースで (PL/SQL または前処理によって) これを行うことはおそらく可能ですが、ロジックはアプリケーション内に保持したいと考えています。したがって、次の2つのいずれかを実行できます。
- LIMIT 句を忘れて、クエリを無制限のままにします。有効な結果が 20 個になるまで行を食べてから、クエリを閉じます。
- チャンクを適用する - LIMIT 40 を指定し、20 個の「良い」結果が得られることを期待します。そうでない場合は、次の 40 などをフェッチします。
2つの実際的な違いは何ですか? 特に。多くの同時ユーザーでのパフォーマンスに関して。
私は PostgreSQL でこれを行っていますが、別の RDBMS に切り替えたいと思っています。(参照整合性を失いたくないので、NoSQL ソリューションを検討していません)おそらく、データベースのいくつかのパラメーター (プリフェッチ サイズなど) を調整して、無制限のクエリ ケースを最大限に活用する必要がありますか?