5

私のアプリケーションには、トピックへの応答の表があります。構造はおおよそ次のとおりです。

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つのいずれかを実行できます。

  1. LIMIT 句を忘れて、クエリを無制限のままにします。有効な結果が 20 個になるまで行を食べてから、クエリを閉じます。
  2. チャンクを適用する - LIMIT 40 を指定し、20 個の「良い」結果が得られることを期待します。そうでない場合は、次の 40 などをフェッチします。

2つの実際的な違いは何ですか? 特に。多くの同時ユーザーでのパフォーマンスに関して。

私は PostgreSQL でこれを行っていますが、別の RDBMS に切り替えたいと思っています。(参照整合性を失いたくないので、NoSQL ソリューションを検討していません)おそらく、データベースのいくつかのパラメーター (プリフェッチ サイズなど) を調整して、無制限のクエリ ケースを最大限に活用する必要がありますか?

4

2 に答える 2

3

Postgres の詳細について話すことはできませんが、クエリ オプティマイザーがさまざまな実行プランのコスト計算の一部として LIMIT 句を使用する可能性があります。

もし、あんたが ...

select ... from ... where ... limit n

その場合、オプティマイザは n 行のみを取得することを認識していますが、...

select ... from ... where ... 

オプティマイザは、数千行と推定される結果セット全体が必要であると想定する場合があります。

特に、RDBMS では、LIMIT 句が適用されるインデックス ベースのアクセス方法が優先されると思います。

于 2012-11-08T17:55:48.027 に答える
1

SQL でブロック リストを追加することは難しくありません。

SELECT * FROM responses 
WHERE topic_id=123 
    AND author_id NOT IN (SELECT author_id FROM blocked WHERE user_id = X)
ORDER BY id DESC LIMIT 20;

NOT IN を WHERE 句に追加するだけです。

これを行うことができない何らかの理由がある場合は、チャンクのアイデアが最適です。データベースはクエリを実行するクライアントまたはサーバーにすべてを返すため、制限を設けたくありません。

于 2012-11-08T17:45:36.070 に答える