私は iOS 7 でコーディングしており、私のアプリは Core Data を使用しています。Core Data はうまく機能しています。
コア データのサイズと残りの空き容量を表示するルーチンを作成しましたが、表示されている内容に少し混乱しています。
私の Core Data は、Next_ID.sqlite、PhotoSm.sqlite、PhotoLg.sqlite の 3 つのファイルで構成されています。
新しい DB を作成したときの結果は次のようになります。
Next_ID = 36,864 bytes
PhotoSm = 36,864 bytes
PhotoLg = 36,864 bytes
Free = 1,507,385,344 bytes
データベースに 10 個または 15 個のアイテムを追加すると、数字は次のようになります。
Next_ID = 14,888,960 bytes
PhotoSm = 36,864 bytes
PhotoLg = 36,864 bytes
Free = 1,488,846,848 bytes
まず、Next_ID が文字通り、DB に新しいデータを追加するたびに増加する一意の整数を保持するためにのみ使用されるほど大きく変更されたことに驚きました。
次に驚いたのは、PhotoSm も PhotoLg も変わっていないことです。
最後に、料金スペースの変化は、18,538,496 バイトが消費されたことを示しました。しかし、Next_ID の変更は、14,852,096 バイトしか使用されていないことを示しています。したがって、3,686,400 バイトが不足しているようです。
これらは私の質問です：
Q1: Next_ID.sqlite、PhotoSm.sqlite、PhotoLg.sqlite は SQLite データベース内のテーブルであるため、個々のテーブルの大きさを尋ねるのはおそらく意味がありませんか?
Q2: Next_ID.sqlite テーブルのサイズが変更されたという事実は、データベースのサイズを変更したときにデータベース全体の測定値を取得していることを示唆していますか? これは、DB の最初のテーブルであるために発生しますか?
空の DB を作成したとき、3 つのテーブルはすべてまだ 36,864 バイトのサイズを示していたため、初期構造が存在し、おそらく空のスペースが含まれているようです。
Q3: 3,686,400 バイトが失われることを心配するのは、DB のサイズとそこに入れられるデータのサイズの間に 1 対 1 の関係がないため、ばかげたことになるのでしょうか?
これらの考えが正しければ、次のようになります。
Q4: テーブル レベルでのクエリの混乱を招くことなく、DB 全体のサイズをクエリする方法があるかどうか疑問に思っていますか?
クエリを実行するために使用しているコードについては、慎重に調べましたが、エラーは発生していません。テストとして、スタックオーバーフローの実際の例のコードに置き換えましたが、常に同じ結果が得られました結果。