私はこれが循環参照であることを知っているが、なぜこれが悪いのかを理解することは難しい

私たちは、ETLの作業を別の会社が作成した新しいデータベースに取り入れる必要がある場所でプロジェクトを実行しています。開発者が私に与えたデータベースダイアグラムを見ているうちに、私はテーブルのうちの4つに循環参照があることを見ました:

私はダイアグラムをアップロードすることはできませんが、ここにはテーブルの一般的な構造があります:

場合

  • ID (PK) 場合StatusInfo (FK)
  • サインオフプランニング (FK)
  • SignOffReportReview (FK)
  • SignOffQuarterlyReview (FK)

場合StatusInfo

  • ID (PK)
  • 場合Id (FK)

サインオフプランニング

  • ID (PK)
  • 場合Id (FK)

SignOffReportReview

  • ID (PK)
  • 場合Id (FK)

SignOffQuarterlyReview

  • ID (PK)
  • 場合Id (FK)

How these Info tables linked to the 場合 table will be used is that it will be storing historic statuses of a 場合 by having the primary key stored within each Info table. This really does make logical sense but i feel that it might have been better to normalize these tables even further to keep the historic data in those normalized tables.

私の質問は次のとおりです。テーブルをさらに正規化するのではなく、このタイプのデータベース構造を持つことによって、どのような問題が発生する可能性がありますか?

0
nl ru de

1 答え

あなたは本当にこれらのテーブルと1-1の関係が必要なように思えます。私はテーブルのそれぞれが他のプロパティのヒープを持っていると仮定しているので、あなたはなぜそれらを巨大な場合テーブルに結合したくないのか理解できます。その場合、PK/FKを組み合わせて1-1の関係を強制したいかもしれません...

場合

  • ID (PK)
  • 場合StatusInfo (FK)
  • サインオフプランニング (FK)
  • SignOffReportReview (FK)
  • SignOffQuarterlyReview (FK)

場合StatusInfo

  • 場合Id (PK, FK)

サインオフプランニング

  • 場合Id (PK, FK)

SignOffReportReview

  • 場合Id (PK, FK)

SignOffQuarterlyReview

  • 場合Id (PK, FK)
0
追加された
あなたが私の答えを注意深く見ると、cirular referencesはなくなっていますか?もちろん、CaseStatusInfo、SignOffPlanning、SignOffReportReviewおよびSignOffQuartelyReviewは、ケースが削除されても存在できません。しかし、これはあなたのテーブルでもそうです(CaseIdがそれらのテーブルでnullableでない限り)。しかし、あなたは「歴史的なデータ」のケースデータも保持していると思います。
追加された 著者 Felix,
これらのテーブルのうちの1つを挿入すると、CaseId = Case.Idが関連するケースレコードに挿入されます。
追加された 著者 Felix,
こんにちはフェリックス。私は1-1の関係が欲しいですが、循環参照は避けてください。彼らが私に説明したように、この構造は歴史的なデータを保持するのに役立ちます(私はこれが怠け者だと感じています)。この構造の私の嫌いに加えて、循環参照の事実の他に、この設計を使用するのにどんな問題があるのか​​わからない。
追加された 著者 Henry,