データベース內(nèi)の複雑な 1 対多対多の関係を避けるために、私のデータベースの設(shè)計(jì)では、テーブル內(nèi)のフィールドに外部キーを持たないようにしています。関係は、セッターとゲッターを使用して手動(dòng)で関連付けられます。しかし、プログラムを書いて機(jī)能を?qū)g現(xiàn)することはできるのですが、ゲッターやセッターをたくさん書くのは大変だった、最初からそのように設(shè)計(jì)すべきではなかったのか、ということがわかりました
この設(shè)計(jì)は非常に優(yōu)れていますが、データベース抽象化レイヤー (ROM) が不足しているだけです。
データベース理論には、CAPと呼ばれる概念があります。
CAP 理論は、分散アプリケーションを設(shè)計(jì)および展開する際に 3 つのコア システム要件があり、これら 3 つの要件の間には特定の特別な関係があります。要件は以下の3つです
C: 一貫性
A: 可用性
P: パーティショントレランス
CAP 理論の核心は次のとおりです。 分散システムは、一貫性、可用性、およびパーティションの耐障害性の 3 つの要件を同時(shí)に満たすことはできません。 同時(shí)に満たせるのは 2 つだけです。
そしてほとんどの nosql データベースは C (一貫性) に関して妥協(xié)しています。
したがって、外部キーを放棄するのが賢明です。外部キーはすべてのデータの一貫性を維持するために使用されますが、多くの場(chǎng)合、リアルタイムでデータの一貫性を保つ必要はまったくなく、最終整合性 を確保することのみが必要です。
http://www.csdn.net/article/2...
http://duanple.blog.163.com/b...
1. 現(xiàn)在、インターネットでは基本的に外部キーが使用されていません。
2. get set 問題については、Lombok を試してみてください。
実際のアプリケーションでは、通常、プログラムを使用して外部キーを制御します。データベースレベルではありません。
第一に、リレーショナル データベースの外部キー (ここでは特にマッピング関係と呼ばれます) は依然として非常に役立ちます。
第二に、外部キー (ここでは特に外部キー制約と呼ばれます) は存在すべきではありません。
外部キーを使用するアプリケーションはますます少なくなっています。 10年前はかなり多かったです。 主にビジネスの獨(dú)立性を考慮したためです。 私はビジネスを完全にアプリケーション側(cè)に置きたいと考えており、データベースは永続化のためにのみ使用されます。
10 年以上前に私がいくつかのプロジェクト データベースに取り組み始めたとき、データベースもビジネスに関與していましたが、その後、メンテナンスが非常に困難であることがわかりました。その後、プロジェクトのメンテナンス中に、すべての問題に対処するために、データベース スペシャリストを追加する必要がありました。この問題はプロジェクトの概要でも取り上げられました。データベーススペシャリストの費(fèi)用は非常に高額です。