私はおそらくこの問題を考えすぎているので、提案とより明確な頭があれば、私はすべて耳を傾けています。
問題は、増え続けるデータをSQLiteデータベースに保存し、NSTableViewユーザーが操作するアプリケーションに表示できるようにしたいことです。単に次のようなものを実装するだけですNSArrayNSDictionary
- (id)tableView:(NSTableView *)tView objectValueForColumn:(NSTableColumn *)column row:(NSInteger)row {
return [[myData objectAtIndex:row] objectForKey:column.identifier];
}
2 つの可能性があります。1 つは、データ セットが大きくなる (>500,000 レコード) ということです。もう 1 つは、コンパニオン アプリによってレコードが挿入され、実行中の他のすべてのインスタンスにメッセージが送信される、ローカル ネットワーク上のデータベース サーバーにデータが到達する可能性です。テーブルで a を行うreloadData- ただし、今のところ 2 番目についてはあまり気にしません。デフォルトのビューでは、すべてのレコードが表示され、フィルタによってそれらが削減されます。
それで、OSXのメモリ管理はディスクベースのキャッシュなどにそれをシャッフルするだけなので、NSArray / NSDictionaryにどれだけのデータがあるか心配する必要があります。
または、NSArray を非常に軽量にし、データベース内のレコードに一意の ID を保持し、必要に応じてそれぞれをフェッチするというアイデアを検討する必要があります-SQLite はアプリに対してローカルであるため、これはルックアップに費用がかかりますが、衰弱させることはありません想像します. いずれにせよ、このメソッドは、すべてを表示するシナリオとフィルター処理された結果を表示するシナリオの両方を満たします。
この時点ではカスタム セルを使用していないので、再利用キューなどについては OS に任せ、後でそのブリッジを渡ります。
アプリケーションのモデルで現在の行をキャッシュして、各列の値がデータ オブジェクトからの単なるルックアップになるようにする必要がありますか?
コア データについては検討しましたが、アップスケーリングの要件が後で障害になる可能性があり、Apple のドキュメント スタイルの限界点に達しています。