この設計は非常に優れていますが、データベース抽象化レイヤー (ROM) が不足しているだけです。

データベース理論には、CAPと呼ばれる概念があります。

CAP 理論は、分散アプリケーションを設計および展開する際に 3 つのコア システム要件があり、これら 3 つの要件の間には特定の特別な関係があります。要件は以下の3つです

C: 一貫性
A: 可用性
P: パーティショントレランス

CAP 理論の核心は次のとおりです。 分散システムは、一貫性、可用性、およびパーティションの耐障害性の 3 つの要件を同時に満たすことはできません。 同時に満たせるのは 2 つだけです。

そしてほとんどの nosql データベースは C (一貫性) に関して妥協しています。

したがって、外部キーを放棄するのが賢明です。外部キーはすべてのデータの一貫性を維持するために使用されますが、多くの場合、リアルタイムでデータの一貫性を保つ必要はまったくなく、最終整合性 を確保することのみが必要です。

• http://www.csdn.net/article/2...

• http://duanple.blog.163.com/b...

1. 現在、インターネットでは基本的に外部キーが使用されていません。
2. get set 問題については、Lombok を試してみてください。

実際のアプリケーションでは、通常、プログラムを使用して外部キーを制御します。データベースレベルではありません。

第一に、リレーショナル データベースの外部キー (ここでは特にマッピング関係と呼ばれます) は依然として非常に役立ちます。
第二に、外部キー (ここでは特に外部キー制約と呼ばれます) は存在すべきではありません。

外部キーを使用するアプリケーションはますます少なくなっています。 10年前はかなり多かったです。 主にビジネスの独立性を考慮したためです。 私はビジネスを完全にアプリケーション側に置きたいと考えており、データベースは永続化のためにのみ使用されます。

10 年以上前に私がいくつかのプロジェクト データベースに取り組み始めたとき、データベースもビジネスに関与していましたが、その後、メンテナンスが非常に困難であることがわかりました。その後、プロジェクトのメンテナンス中に、すべての問題に対処するために、データベース スペシャリストを追加する必要がありました。この問題はプロジェクトの概要でも取り上げられました。データベーススペシャリストの費用は非常に高額です。