スキーマ設計に関するアドバイス - MongoDBまたは潜在的Neo4J

Question

私は、個人的な使用のための簡単な会計プログラム（平均スタック）を構築しています。私はそれに精通しているので、私はMongoに達しましたが、私はスキーマを洗い流しているので、私は疑問を持っています。私は自分の考えを提示し、おそらくそれを行う別の方法についての提案を求めたい。

任意の数の勘定科目の元帳に同じ取引が表示されているので、私の現在の考えは、トランザクションをアカウントのサブ文書としてではなく、独自のコレクションとして（複製を避けるため）保管することでした。

var accountSchema = new mongoose.Schema({ 
    name: String, 
    // etc 
}); 

var entrySchema = new mongoose.Schema({ 
    amount: Number, 
    account: {type: mongoose.Schema.Types.ObjectId, ref: 'Account'} 
}); 

var transactionSchema = new mongoose.Schema({ 
    date: Date, 
    debits: [entrySchema], 
    credits: [entrySchema] 
}); 

これは私には、データを格納するための論理的な方法思えますが、いくつかの明白なクエリの懸念があります：重要でないビットを残して、それは次のようになります。たとえば、口座の元帳を表示する場合は、その期間のすべてのトランザクションを繰り返す必要があります。それぞれのトランザクションについて、そのアカウントが関与しているかどうかを確認するために、クレジットとデビットの両方のコレクションを繰り返します。

私はグラフのdbsの経験はありませんが、私はNeo4Jのようなものがこのタイプのデータを照会する方が適しているかもしれないと考えていました。私の質問は、あなたは同意しますか、それともMongoはまだ良い選択ですが、スキーマについて間違っていると思いますか？

Answer 1

はい、あなたは正しいです。 Neo4jは、接続されたデータを扱う際の良い選択です。

あなたの現在の戦略は、基本的に他のスキーマ（一種の外部キー）からの識別子への参照を埋め込むことです。問合せ時には、ジョインのような操作を完全にスキャンする必要があり、データベースのサイズが大きくなるにつれて非常に高価になります。

また、これらの参照データの更新や削除には注意が必要です。そうしないと、データの一貫性が失われます。

Neo4jのようなグラフデータベースを使用すると、データモデルはグラフになります。シナリオにはより自然で直感的です。私は完全にあなたの要件とシナリオを理解していないが、私は、グラフのデータモデルは、のようなものにできると信じています：

あなたのグラフを照会するCypher Languageの電源を使用することができますこの方法です。あなたが安いコストでグラフを横断して照会するインデックスのない隣接の利点を取ることができ

MATCH(a:Account)<-[:ENTRY_TO]-(e:Entry)<-[:CREDIT]-(t:Transaction) 
WHERE a.id = 10 AND t.date > "2017-10-10" 
RETURN e 

：あなたが行うことができます「2017年10月10日」以来たとえば、特定のアカウントからすべてのクレジットを取得するには結合操作が必要ないためです。

Neo4jとグラフデータベースに精通していないので、無料のオンライントレーニングgetting started with Neo4jをご覧ください。また、電子書籍：Graph Databases（Ian Robinson、Jim Webber、EmilEifrém）とLearning Neo4j（Rik Van Bruggen提供）を無料でダウンロードできます。