MongoDBRealmSyncでのサブコレクションのモデリング

あなたのコードは見栄えが良く、正しい方向に向かっているので、この答えはハードコードよりもモデリングに関するより多くの説明と提案です。

まず、レルムオブジェクトは lazilyロード済みつまり、使用時にのみロードされます。何万ものオブジェクトがデバイスのメモリに与える影響はほとんどありません。したがって、10,000人のユーザーがいて、「すべてをロードする」と仮定します。

let myTenThousandUsers = realm.objects(UserClass.self)

まあ、大したことはありません。ただし、これを行う

let someFilteredUsers = myTenThousandUsers.filter { $0.blah == "blah" }

問題が発生する（可能性がある）-それが10,000人のユーザーを返す場合、すべてのユーザーがメモリに読み込まれます おそらくデバイスを圧倒します。これはSwift関数であり、Swiftを使用したレルムの遅延データの「変換」は一般的に回避する必要があります（ユースケースに依存します）

Swift .forEach

を使用したこのコードの観察

realm.objects(Project.self).forEach { (project) in
   // Access fields     
}

これらのプロジェクトオブジェクトで何が行われているかによっては、問題が発生する可能性があります。オブジェクトが多数ある場合、それらをtableViewdataSourceとして使用すると問題が発生する可能性があります。

2つ目は、ドキュメントあたりの16Mbの制限についての質問です。わかりやすくするために、Atlasドキュメントはこれです

{
   field1: value1,
   field2: value2,
   field3: value3,
   ...
   fieldN: valueN
}

ここで、valueは、他のドキュメント、配列、ドキュメントの配列など、任意のBSONデータ型にすることができます。

構造体では、var tasks = RealmSwift.List<Task>() ここで、タスクは埋め込みオブジェクトです。。概念的に埋め込まれたオブジェクトはオブジェクトですが、埋め込まれているため、単一のドキュメント制限にカウントされると思います（間違っている場合は修正してください）。それらの数が増えると、それを囲むドキュメントのサイズも大きくなります。16Mbのテキストは膨大な量のテキストであるため、プロジェクトごとに数百万のタスクに相当することに注意してください。

簡単な解決策は、それらを埋め込まず、自立させることです。

class Task: Object {
    @objc dynamic var _id: String = ObjectId.generate().stringValue
    @objc dynamic var _partition: String = "" 
    @objc dynamic var name: String = ""
    @objc dynamic var status: String = "Pending"
    override static func primaryKey() -> String? {
        return "_id"
    }
}

次に、それぞれを16Mbにすることができ、「無制限の数」を1つのプロジェクトに関連付けることができます。埋め込みオブジェクトの利点の1つは、親オブジェクトが削除されると子オブジェクトも削除されるタイプのカスケード削除ですが、プロジェクトからタスクへの1つの多くの関係により、親に属する一連のタスクを簡単に削除できます。

ああ-埋め込みオブジェクトを使用しない別のケース-特にこのユースケース-は、インデックス付きのプロパティを持つことができないということです。インデックス作成一部のクエリを大幅に高速化できます。