データベース内の複雑な 1 対多対多の関係を避けるために、私のデータベースの設計では、テーブル内のフィールドに外部キーを持たないようにしています。関係は、セッターとゲッターを使用して手動で関連付けられます。しかし、プログラムを書いて機能を実現することはできるのですが、ゲッターやセッターをたくさん書くのは大変だった、最初からそのように設計すべきではなかったのか、ということがわかりました
巴扎黑2017-05-17 10:10:09
この設計は非常に優れていますが、データベース抽象化レイヤー (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...
世界只因有你2017-05-17 10:10:09
第一に、リレーショナル データベースの外部キー (ここでは特にマッピング関係と呼ばれます) は依然として非常に役立ちます。
第二に、外部キー (ここでは特に外部キー制約と呼ばれます) は存在すべきではありません。
曾经蜡笔没有小新2017-05-17 10:10:09
外部キーを使用するアプリケーションはますます少なくなっています。 10年前はかなり多かったです。 主にビジネスの独立性を考慮したためです。 私はビジネスを完全にアプリケーション側に置きたいと考えており、データベースは永続化のためにのみ使用されます。
10 年以上前に私がいくつかのプロジェクト データベースに取り組み始めたとき、データベースもビジネスに関与していましたが、その後、メンテナンスが非常に困難であることがわかりました。その後、プロジェクトのメンテナンス中に、すべての問題に対処するために、データベース スペシャリストを追加する必要がありました。この問題はプロジェクトの概要でも取り上げられました。データベーススペシャリストの費用は非常に高額です。