MySQL を DB として使用し、休止状態とストラットを使用するアプリケーションがあります。これを Hibernate と MySQL の代わりに Neo4J を使用するように変換する作業を行っています。構造は少し異なり、関係の新しい考え方です - それらはより生き生きとしています。とにかく、私は会社ノードとの関係を持つ人物ノードを持っており、その関係が採用されています。したがって、人は会社に雇われています。人にもスキルがあり、そのスキルは企業に勤めながら身につけることができます。だから私はどういうわけか雇用関係からスキルに移行する必要があります.
関係はノードからノード (エッジ) への単なる結び付きであるため、関係から関係へと移行することはできません。したがって、これらのオブジェクトをより適切に関連付ける方法を考える必要があると確信しています。どういうわけか雇用関係を経験としてノードに分割することを考えていました。したがって、人には経験があります。彼らは企業に就職することでこの経験を積んだ。彼らはこの経験からこれらのスキルを身につけました。これは理にかなっていますが、ノードを「具体的な」情報として考え、そこから始めて他の「具体的な」情報に戻ることができ、ノードでの経験を持つことは正しくないようです. それは漠然としていて、関係の中に保存されるべきもののように思えます。それが今の私のやり方なので、振り出しに戻ります。
私が苦労しているもう1つのことは、経験をノードに分割することがこれに役立つかもしれないということですが、人は同じ会社から複数の種類の経験を得ることができるということです。ですから、同じ会社を指し示すさまざまな経験に複数の関係を持つ人が必要です。それは問題ありません。複数の経験を持つために複数の関係を持つことは理にかなっています。企業が誰を雇用したかを確認するのは、長い道のりのようです。
たぶん、経験はポジションのようなものかもしれません。会社には役職があり、その役職にはこれらのスキルが関連付けられていることが知られています。ポジションは人によって満たされ、その人はそのポジションにすでに関連付けられているものにスキルを追加できます。ただし、追加するスキルはデフォルトで追加する必要はないため、位置とスキルの関係にフラグを立てる必要があります。
うーん、うまくいくかもしれません。他の誰もが、Neo4J または任意のグラフ データベースを使用して、この種のドメイン構築の問題に実際に苦労しています。これは間違いなく、データ構造に対する新しい考え方です。学んだすべての rdbms の知識と「ルール」を忘れるのがほとんど最善です。