1

「アイテム」などのデータベーステーブルがあります。これらのアイテムのタイムラインをフィールド ascended_at (datetime) で並べ替えています。そのようなタイムライン用のページネーション API を作成する必要があります。したがって、最初の私のバージョンは次のとおりです。

HTTP GET /items/timeline?page=[PAGE_NUM]

発火する

SELECT * FROM items LIMIT 10 OFFSET [0, 10, 20, ...] ORDER BY ascended_at;

しかし、ここに問題があります。新しいアイテムが到着すると、すべてのページが 1 つのアイテムごとにシフトします。これを避けるために、from_asc_at パラメータを追加しました。

HTTP GET /items/timeline?page=[PAGE_NUM]&from_asc_at=123123123

発火する

SELECT * FROM items WHERE ascended_at <= [asc_at_parameter] LIMIT 10 OFFSET [0, 10, 20, ...] ORDER BY ascended_at;

しかし、これは正確ではありません。なぜなら、2 つのアイテムが同じ ascned_at を持つ可能性があり、同じアイテムが 2 つの異なるページに表示される可能性があるからです (ただし、そうすべきではありません)。

だから、私の質問は次のとおりです。これに対する可能な解決策は何ですか?

  • ID を使用しますか (一意であるため)? しかし、ID 順でない場合はどうなるでしょうか。
  • もっとアイデアはありますか？
4

1 に答える 1

0

アイテム ID が自動インクリメントされている場合、最初にアイテムを取得するとき (ページネーションの前) に、次の「自動インクリメント」値を確認できます。

次の検索までその値を永続的に (おそらくセッション var に) 保存< {maximumID}し、SQL クエリにフィルターを追加して、ユーザーがページネーションを行ったときの「結果セットの安定性」を向上させます (最初の検索とページネーションの間に作成されたすべての新しいアイテムは無効になります)。取得できません)。

編集

アイテムの削除を処理するには、「ソフト削除」を行う必要があります。DB からアイテムをすぐに削除するのではなく、削除日を日時フィールドに保存して、アイテムがしばらくの間 DB に存在するようにします。

新しい検索が発行されると、現在のサーバー時刻をセッションに保存し、基準 (たとえば、date_deleted IS NULL OR date_deleted > {searchDate}) を追加して、検索後に削除されたすべてのアイテムがその特定の検索で引き続き表示されるようにします。

少し遅れてDBからアイテムを「実際に」削除するには、スケジュールされたジョブを作成する必要があります。

于 2013-03-15T11:45:32.820 に答える