概要 （漠然と申し訳ありませんが、もっと詳しく説明すると、物事が複雑になりすぎると思います）
私には3つのテーブルがあり、テーブル1にはIDが含まれ、テーブル2には独自のIDとテーブル1のIDが含まれ、テーブル3には独自のIDとテーブル2のIDが含まれます。
私は多くの時間を熟考してきましたが、テーブル3に関連するテーブルのIDも含める方が効率的だと思います。
-3つのテーブルを結合する必要がないことを意味します。テーブル3をクエリするだけです（非常に頻繁に使用されるクエリの場合）
-テーブル1の特定のIDを含むテーブル3内の行をロックするだけで、予約システムをより簡単に実装できるようになります。
データベースレイアウトについてもっと知りたい人のために、ここにもっと情報があります
質問
非正規化の不利な点は何ですか？完全に反対している人もいれば、正しい状況を信じている人もいるので、それは便利なツールです。IDは変更されないので、同じデータを2回挿入する必要があり、追加のスペースが消費されることを除いて、実際には不利な点はありません（IDであるため、無視できる程度です）。
私のアドバイスは、この一般的なルールに従うことです。デフォルトで正規化し、解決するパフォーマンスの問題を特定した場合は非正規化します。
正規化されたデータとそれを処理するコードは、保守がより簡単で論理的であることがわかりました。非正規化を使用してパフォーマンスを向上させることに問題はないと思いますが、必要であることが確実になるまで、保守性の低下につながるパフォーマンスの最適化を投機的に適用することはありません。
本当に非正規化したいのは、必要なパフォーマンスを得るのに必要な場合だけです。
これはすでに何度か尋ねられました。こちらをご覧ください
正当な理由がある場合は、すべてのルールが破られる可能性があります。
あなたの場合、3つのテーブルには何が含まれているのでしょうか。表3は実際に表2を説明していますか、それとも表1を直接説明していますか？
この場合、表3にself-id、table-two-id、およびtable-one-idを含めることの欠点は、不整合が発生する可能性があることです。表2と表にtable-one-id1がある場合はどうなりますか。間違って表3のone-id15？
これは、データとデータのエンティティ関係によって異なります。私にとっては、矛盾がなく、選択にもう少し時間がかかることがより重要です...
編集：テーブルについて読んだ後、テーブル1のIDをテーブル3（領域）に追加することをお勧めします。テーブル1のIDは結局変更されないため、一貫性がないため比較的節約できます。
1つ（表1）から多数（表2）、もう1つ（表2）から多数（表3）として、3層のように見えるのと同じ構造を維持します。
例えば
また、それらのテーブル内に格納している追加のフィールドによって大きく異なります。
正規化と効率は通常トレードオフですが、正規化は一般的に良いことですが、特効薬ではありません。明確な理由がある場合（そう思われるように）、非正規化は完全に許容されます。
完全に正規化されていないテーブルを含むスキーマには、いわゆる「有害な冗長性」があります。有害な冗長性により、同じファクトが複数の場所に保存されたり、保存する必要のあるファクトを保存する場所がなくなったりする可能性があります。これらの問題は、「異常の挿入」、「異常の更新」、または「異常の削除」として知られています。
簡単に言うと、ファクトを複数の場所に保存すると、遅かれ早かれ、相互に矛盾するファクトが2つの場所に保存され、データベースは、のバージョンに応じて、矛盾する回答を提供し始めます。クエリが見つけた事実。
必要なファクトを保存する場所を確保するために「ダミーレコードを発明する」ことを余儀なくされた場合、遅かれ早かれ、ダミーレコードを実際のレコードのように誤って扱うクエリを作成することになります。
あなたがスーパープログラマーであり、間違いを犯さないのであれば、上記のことを心配する必要はありません。私はそのようなプログラマーに会ったことはありませんが、間違いを犯すことはないと思っている多くの人々に会いました。
慣例として「非正規化」は控えます。それは「シカゴから離れる」ようなものです。あなたはまだあなたがどこに行くのか分かりません。ただし、他の人が指摘しているように、正規化ルールを無視する必要がある場合があります。スタースキーマ（またはスノーフレークスキーマ）を設計している場合、最高のスター（またはスノーフレーク）を取得するには、正規化ルールの一部を無視する必要があります。