ソートされたリストを保存するためのデータベースを設計する方法は？

データベース内にソートされたリストを保存したいと思っています。次の操作を効率的に実行したい。

1. Insert（x）-レコードxをテーブルに挿入します
2. Delete（x）-テーブルからレコードxを削除します
3. Before（x、n）-ソートされたリストでレコードxの前にある 'n'レコードを返します。
4. After（x、n）-ソートされたリストのレコードxに続く 'n'レコードを返します。
5. First（n）-ソートされたリストから最初の 'n'レコードを返します。
6. Last（n）-ソートされたリストから最後の 'n'レコードを返します。
7. Compare（x、y）-テーブルの2つのレコードxとyが与えられ、x> yかどうかを見つけます。

私が考えることができる簡単な方法は、ある種の「ランク」属性をテーブルに保存し、その属性でソートすることでクエリすることです。ただし、この方法では、ランク付きのレコードの挿入/変更はコストのかかる操作になります。より良い方法はありますか？

具体的には、AmazonのSimpleDBを使用してテーブルを実装することを検討しています。ただし、リレーショナルデータベースの一般的な回答も役立つはずです。

負荷プロファイルの更新：

これはWebアプリケーション用に計画しているので、アプリを使用するユーザーの数に依存します。

10万人のアクティブユーザーがいる場合（スーパーオプティミズム：P）、1日あたりの私のおおよその見積もりは

50万の選択、10万の挿入と削除、50万の更新

テーブルは合計で500kまで成長すると予想されます。

更新、挿入、および比較の操作を最適化しようとしています。アイテムのランクは常に変化するため、テーブルを更新し続ける必要があります。

ランクは完全に任意ではなく、他のいくつかのプロパティ（例えば、名前、プレーヤーのスコアなど）からの代わりに誘導された場合、その後に良い見てジョエルの答え。

それは場合で、あなたのデータの任意のプロパティ、そのレコードのあなたのテーブルの列として格納する必要があります。AmazonのSimpleDBが典型的なRDBMSに似ていると仮定すると、この列にインデックスを付け、適切なインデックス戦略で上記のすべてのクエリをすばやく満たすことができます。これはRDBMSの正常な動作です。

挿入と更新のアクティビティが多いだけでなく、読み取りアクティビティが比較的高いことを想定しているため、次のことをお勧めします。

• クエリの大部分がランクに反する場合は特に、ランクでテーブルをクラスター化します。そうでない場合、またはクラスタリングキーの選択がSimpleDBで使用できない場合は、ランクを先頭列としてインデックスを作成します。これにより、クエリ3〜6が満たされます。
• 最初にレコードのインデックス、次にランク（または、SQL Serverの世界では、単にレコードと- INCLUDEランク、または単にランクでクラスター化した場合はレコードのみ）は、クエリ7を満たします。
• 操作1と2は、データを適切に間隔を空ける（つまりFILLFACTOR、SQL Serverで設定する）ことで最適化できます。これは、ランクでクラスター化する場合に特に重要です。
• ランクを挿入または更新するときは、ランクの挿入または更新に対応するために既存のレコードを再ランク付けする必要が生じる可能性を最小限に抑えるために、ランク番号間のギャップをできるだけ維持します。たとえば、1000のステップでレコードをランク​​付けする場合、最小限のチャンスでその半分ほどの変更と挿入に十分な余地を残し、それらの変更に直接関係しないレコードを再ランク付けする必要があります。
• 毎晩、すべてのレコードを再ランク付けして、それらの間のランクギャップをリセットします。
• 大量の再ランク付けの頻度とランクギャップサイズを調整して、既存のレコードの数に対する挿入または更新の予想数に対応できます。したがって、レコード数が10万で、挿入と更新がその10％であると予想される場合は、10Kの新しいランクに十分なスペースを残して、毎晩再ランク付けしてください。
• 50万件のレコードを再ランク付けするのはコストのかかる操作ですが、そのようなデータベースでは、1日1回または1週間に1回は営業時間外に行う必要があります。ランクギャップを維持するためのこの時間外の大量再ランク付けにより、通常およびピーク時間中にランクの更新または挿入ごとに多くのレコードを再ランク付けする必要がなくなります。

100K +サイズのテーブルで100K +の読み取りが予想される場合、リンクリストアプローチの使用はお勧めしません。それらのサイズにうまく対応できません。

私は通常、あなたが説明する「ランク」方式を使用します。アイテムを並べ替える必要があるときに行を更新することに煩わされるのではなく、リスト内のすべてのレコードを削除し、新しいアイテムを適切な順序で再挿入することで、しばしば逃げることができました。このメソッドは、検索用に明らかに最適化されています。

別のアプローチは、テーブルの「先行」再帰的外部キー列を使用して、レコードをリンクリストとしてモデル化することです。

ID   setID   item       predecessor
---  ------  ------     ------------
1    1       Apple      null
2    1       Orange     1
3    2       Cucumber   null
4    1       Pear       2
5    1       Grape      4
6    2       Carrot     3

リストを簡単に取得し、ほとんどオーバーヘッドなしで項目を追加および削除できますが、適切な順序でレコードを取得するのは難しいでしょう。おそらく、多くのエイリアステーブル結合を使用して、1つのクエリでそれを行う巧妙な方法があるでしょう。

ツリースタイルの関係（カテゴリ、フォルダー、セット、およびサブセット）をモデル化するときに、後者のアプローチをよく使用します。私は通常、アプリケーションで完全なツリーを再構築するための何らかの再帰関数を持っています。

私がすべきことは、ランクを計算するために使用されるプロパティを保存し、それらの上にインデックスを構築することだと思います。ランク付けされた順序でデータベースにデータを物理的に保存するように強制したり、手動で管理されたリンクリストを使用したりするのではなく、データベースエンジンに設計どおりの動作をさせてみませんか？

これらは、simpleDBのような非RDBMSの制限です。必要な機能をsimpleDBのDB側に実装することはできません。プログラミング側/アプリケーションから実装する必要があります。

のようなRDBMSの場合SQL server、必要な機能はクラスター化インデックスの基本です。

• Insert（x）-レコードxをテーブルに挿入>単純挿入。
• Delete（x）-テーブルからレコードxを削除>単純な削除。

• Before（x、n）-ソートされたリストでレコードxの前にある 'n'レコードを返します。>上位n個の結果を選択します。ここで、xは値より小さく、order by句です。

• After（x、n）-ソートされたリストのレコードxに続く 'n'レコードを返します。>上位n個の結果を選択します。ここで、xはvalueより大きく、order by句です。

• First（n）-ソートされたリストから最初の 'n'レコードを返します。>上位n個の結果を選択します。

• Last（n）-ソートされたリストから最後の「n」レコードを返します。> descで注文した後、上位n個の結果を選択します。

• Compare（x、y）-テーブルの2つのレコードxとyが与えられ、x> yかどうかを調べます。> TSQL IFステートメント。

以下は、挿入ごとにPostgresテーブルを再ランク付けするために使用したものです。

CREATE OR REPLACE FUNCTION re_rank_list() RETURNS trigger AS $re_rank_list$
DECLARE
    temprow record;
    row_idx integer := 1;    
BEGIN
    FOR temprow IN
    SELECT * FROM your_schema.your_list WHERE list_id = NEW.list_id ORDER BY rank ASC
    LOOP
        UPDATE your_schema.your_list SET rank = row_idx * 100 WHERE id = temprow.id;
        row_idx := row_idx + 1;
    END LOOP;
    RETURN NEW;
END;
$re_rank_list$ LANGUAGE plpgsql;


CREATE TRIGGER re_rank_list AFTER UPDATE ON your_schema.your_list_value
    FOR EACH ROW 
    WHEN (pg_trigger_depth() = 0)
    EXECUTE PROCEDURE re_rank_list();

私のユースケースでは、パフォーマンスは問題ではありませんが、決して壊れたり、奇妙に動作したりしないという自信が重要です。