UITableView の作成に sqlite を使用するには、すべてのデータを NSArrays/Dicts にコピーして、リストを前後に移動できるようにします。しかし、これは無駄であり、データを 2 回取得する必要があります。
持つことが可能かどうか、[FMResultSet previous]および/または[FMResultSet goRecord:RECNO]コピーを取り除き、FMResultSet を直接使用できるかどうか疑問に思います。
では、sqlite API はこの可能性を提供しますか?
SQLite の作成者である Richard Hipp が、なぜ SQLite には後退する機能がないのか、そしてなぜこれが一般的に非常に難しい問題なのかについて書いた素晴らしい記事があります。この記事では、興味深いと思われるいくつかの回避策についても説明します。
その記事を引用すると、
上記の sqlite3_step() 関数は、結果セットを通してカーソルを前方に進めているようです。結果セットを逆方向に移動する対応する sqlite3_step_backwards() 関数がない理由を尋ねるのは自然なことです。結局のところ、sqlite3_step_backwards() は簡単に実装できるはずです。前方ではなく、結果セットを後方に移動するだけです...
しかし、それはまったく簡単ではありません。実際、SQLite の設計者は、一般的なケースで機能するアルゴリズムを考え出すことができませんでした。上記の単純なクエリの例など、一部の特殊なケースでは、結果セットをさかのぼって簡単に戻ることができます。しかし、たとえば、クエリが結果列と WHERE 句の両方にサブクエリを持つ 4 方向の LEFT OUTER JOIN である場合など、事態はさらに複雑になります。
問題は、sqlite3_step() 関数が事前に計算された結果セットをまったく処理しないことです。問題を考えるためのより適切で現実的な方法は、準備された各ステートメントが実際にはコンピューター プログラムであると想定することです。このプログラムをデバッガーで実行していて、計算の奥深くにある単一のステートメントにブレークポイントが設定されています。sqlite3_step() 関数を呼び出すことは、デバッガーの [実行] ボタンを押して、プログラムが終了するかブレークポイントに到達するまでプログラムを実行するようにデバッガーに要求するようなものです。Sqlite3_step() は、ブレークポイントに到達すると SQLITE_ROW を返し、終了すると SQLITE_DONE を返します。ブレークポイントに到達すると、「行」の値を見つけるためにローカル変数を調べることができます。次に、「実行」を押すことができます
この観点から (SQLite が内部でどのように機能するかに非常に近い)、sqlite3_step_backward() ボタンを要求することは、シンボリック デバッガーが逆方向に実行できるか、その実行を前のブレークポイントに「元に戻す」ことができると期待するようなものです。 . デバッガがこれを実行できると合理的に期待する人は誰もいないので、SQLite が sqlite3_step_backward() を実行できると期待するべきではありません。