8

私のアプリケーションは、データベースから複雑なデータ構造に大量のデータをロードします。インメモリデータ構造はデータベースの構造に似ています。つまり、データベースに次のテーブルが含まれている場合：

  • テーブルA、キーはA1です
  • テーブルB、キーはB1、列の1つはテーブルAの[キー]への外部キーです
  • テーブルC、キーはC1、列の1つはテーブルBの[キー]への外部キーです

次に、クラスA、B、Cがあり、次のようになります。

  • Bのデータメンバー（B :: m_a）はAへのポインタです
  • Cのデータメンバー（C :: m_b）はBへのポインターです

これは、データベースをロードする場合、正しい順序でロードする必要があることを意味します。最初にCをロードすると、ポイントする必要のあるインスタンスがロードされていないため、値C::m_bを設定できないというメッセージが表示されます。

問題は、他のテーブルの1つ（たとえばC）への外部キーである列もAにある場合です。

すべての外部キーを文字列としてロードし、すべてのデータがロードされた後にルックアップを実行することで問題を解決できますが、何百万ものレコードをロードしなければならないことがあるため、これらにメモリを費やす余裕はありません（一時的ではありますが） ）文字列。

優れた設計（たとえば、「大規模C ++ソフトウェア設計」という本）について読んだことがあるので、循環参照を使用するのは悪い考えだと思います。たとえば、ファイルXHにYHが含​​まれているが、YHにもXHが含まれている場合は、設計が不適切である可能性があります。クラスXがクラスYに依存している場合、またはその逆の場合は、設計が不適切である可能性があります。この依存関係を抽出し、XとYに依存する3番目のクラスZを導入することで解決する必要があります（XとYは相互に依存しなくなります） 。

このデザインルールをデータベースデザインにも拡張するのは良い考えですか？言い換えれば、外部キーの循環参照を防ぐことです。

4

4 に答える 4

8

データモデリングの観点からは、循環的な依存関係で根本的に「間違った」ものは何もありません。モデルが間違っているという意味ではありません。

残念ながら、ほとんどのSQL DBMSは、複数のテーブル更新をサポートしていないため、このような制約を効果的に実装できません。通常、これを回避する唯一の方法は、1つ以上の制約を一時的に一時停止するか（たとえば、「延期可能な」外部キーまたは同様の機能を使用）、またはモデルを変更して制約の一部をオプションにする（参照列の1つを新しいテーブル）。これはSQLの厄介な制限の回避策にすぎませんが、最初から何か間違ったことをしたという意味ではありません。

于 2010-10-08T15:06:36.053 に答える
4

持っているデータをモデル化する必要があります。データに循環関係がある場合（たとえば、各写真はフォルダーに属していますが、各フォルダーには1枚のカバー写真があります）、データベースで循環関係としてモデル化するのが正しいです。

Oracleを使用しているときにこのような状況が発生したのは一度だけだったため、他のデータベースにこのような関係を実装する方法を確認する機会がありませんでした。しかし、Oracleの場合は、ここで私の記事を読むことができます。

http://www.databasesandlife.com/circular-dependencies-on-foreign-key-constraints-oracle/

于 2010-12-02T17:24:47.003 に答える
1

はい、データベースの周期的な依存関係は、設計を再考するための良い言い訳です。

于 2010-10-08T14:33:58.923 に答える
1

循環参照が必要になるのは、組織ツリーなどの階層構造を作成するときだけです。

Table Employees
   EmployeeID   <----------|
   SupervisorEmployeeID ---|
于 2010-10-08T14:36:08.297 に答える