6

Datomic のより慣用的なスキーマについて質問があります。

Userと のエンティティがあるPostとしましょうTopic。

PostTopic、Userおよびその他Post(返信)に属することができます。さて、私は、

a) s の:posts単なるリストである属性を作成し、多数のsPostへの参照を必要とするすべてのエンティティにそれを挿入しますか?Post

また

b) aが User への参照である属性を持ち、おそらくaまたは another のいずれかを参照できる属性をPost持つように、より明示的な関係を確立しますか?:post/author:post/belongs-toTopicPost

観察: bを実行すると、より意味的な関係が得られるようです。私は例えば を行うことができます(:post/_author user-entity), これは彼らの関係の性質をより説明しています(なぜなら, aが を持っている(:posts user-entity)とはどういう意味ですか? それらはs のお気に入りの ですか, 作成された ですか?)User:postsUserPostPost

bのもう 1 つの副作用はPost、他のエンティティを変更せずに新しいものを作成できることです。を実行する場合、 を作成し、それを の属性にPost挿入する必要があり、1 回ではなく 2 回の操作が必要になります。:postsUser

しかし、私はそれを行うより慣用的な方法かもしれないと感じています。たとえば、属性を介して参照するのではなく、参照:postsする場合、属性のリストが時間の経過とともにどのように変化したかを確認する方が簡単だと思われます。User:postsPostUser:post/author

何が望ましいでしょうか、またその理由は何ですか?

4

2 に答える 2

6

あなたのオプション（b）は本質的に慣用的であり、データミックに進む唯一の方法です。

すべてのデータスキーマは、entity-attribute-value データム (EAV) の構造で属性が取り得る値としてのみ成文化されます。

http://docs.datomic.com/schema.htmlを参照してください- ドキュメントから取られた重要な命題は次のとおりです。

各 Datomic データベースには、エンティティに関連付けることができる一連の属性を記述するスキーマがあります。スキーマは、属性自体の特性のみを定義します。どの属性をどのエンティティに関連付けることができるかは定義しません。

エンティティ自体は非常に抽象的で (内部的には単なる数値です)、エンティティのすべての興味深いプロパティは属性値アサーションとして体系化されています。エンティティは型付けされていません! エンティティのセマンティクスは、:user/firstname、:post/title、:post/content、:topic/description などのようにアサートする属性によって作成されます。これが、本当に属性に名前を付けたい理由です。

これの特殊なケースは:db.type/ref、EAV の「V」の値自体が別のエンティティである属性タイプです。これが、エンティティ間のセマンティック アソシエーションを作成するものです。:db/identE<->E 接続が実際に何を意味するかを把握するために、各属性に ( として) 「名前」を付けます。:db.type/refしたがって、:db/ident「:post/author」の属性を持つことができます。

すべての:db.type/ref属性は本質的に双方向であるため、Euがユーザーを表すEpエンティティであり、 が投稿を表すエンティティである場合、以下はデータトムの作成とクエリの両方で同等であることに注意してください。

[Ep :post/author  Eu]
[Eu :post/_author Ep]

単なる属性アサーションであるすべてのエンティティ関係は、非常に柔軟です。後でお気に入りの投稿の概念を追加したい場合、それは の別の属性です:db.type/ref。:db/ident「:user/favorites」などで作成し、既存のユーザーと投稿 (作成者として異なるユーザー エンティティを持つ) の間の接続をアサートします。

[aUser :user/favorites somePost]

コレクション値の属性の概念がないため、( a ) で提案することはデータ型では適切に表現できません。クエリを使用して投稿を集約します。削除後の投稿は、エンティティ自体の撤回によってモデル化されます。このような撤回された投稿は、データベース履歴に表示されたままになります。

これは、エンティティのリストの順序を指定する方法の課題を作成します。投稿の日付などの「自然な」順序付け (データトミック トランザクションで、または投稿の明示的な属性として取得) を使用するか、:post/up- などを介して明示的な属性値ベースの順序付けを使用する必要があります。投票数値属性。

エンティティのセマンティック グループ化が必要な場合、"サブエンティティ" は意味があるだけで、より大きなものの一部としてのみ存在します (たとえば、注文のライン アイテム エンティティ)。

于 2013-12-30T18:13:45.973 に答える
0

それは主にアクセスパターンに依存すると思います。関連する投稿を埋め込むことができるエンティティにアクセスするたびにそれらの投稿が必要な場合は、それらを埋め込むことが理にかなっています ( a )。ほとんどの場合、それらに個別にアクセスする場合は、それらを分離する方がよい場合があります ( b )。

または、別々の Post エンティティを正規のものと見なし、さまざまなエンティティに埋め込まれたものをキャッシュバージョンと見なすことで、両方を行うことができます ( c )。このように、正規バージョンが更新されるたびに埋め込み投稿を更新するスクリプト/バッチが必要です。これにより、情報が常に存在するため、すべての読み取りが容易になりますが、自分で同期を維持する必要があるため、書き込みはより複雑になります。また、このパターンは、標準バージョンと組み込みバージョンの間の不一致を受け入れることができ、再同期の遅延が重要でない場合にのみ使用できます。

注 :このアドバイスは特に Datomic とは関係ありません。これらは NoSQL の世界から借用した手法であり、決して私が専門家ではありません。

于 2013-11-21T09:22:53.073 に答える