TABLE-AはTABLE-Bに1つ以上の行を持つことができ、TABLE-Cには1つ以上の行を持つことができ、TABLE-Dには1つ以上の行を持つことができます...など。
私がTABLE-Zにいて、TABLE-Aについての詳細を知る必要があるとしましょう。TABLE-ZからTABLE-Aまで機能するSQLクエリを作成しますか？ある時点で、たとえば、TABLE-ZがTABLE-Aに対してFKを持っていて、クエリがそれほど苦痛にならないようにするといいかもしれません。しかし、そのFKを置くと、正規化を破ることになると思いますよね？
これに対処する方法に関する一般的なアドバイスはありますか？
複合主キーを使用する場合（テーブルを作成する前にデザインを正しくモデル化した場合に実際に発生します）、TableAのキーはすでにTableZに含まれています（左端の列として）。
ただし、人々は通常、理由を理解せずに代理キーを追加します。したがって、これには、TableAとTableZの間のリンクを確立するために、26個のテーブルすべてを結合する必要があります。
TableAとTableZの間の余分なFKは、いくつかの中間外部キーと競合する可能性があります。これが、非正規化（または非正規化）データに固有のリスクがあり、慎重に使用する必要がある理由です。
ただし、通常、26レベルのネストされたテーブルはありません。2、3、または6ウェイの主キーを使用するということは、中間テーブルなしでTableAをTableFに結合できることを意味します。
個人的には、既知の再現可能で実証可能なボトルネックがない限り、複合キーを使用し、余分なFKを避けます。ほとんどのデータベースは違いに気付かないでしょう。だからまだ最適化しないでください
場合によっては、クエリの時間/メモリ使用量がテーブルの正規化を維持することよりも重要である場合、テーブルを非正規化することは許容されます。数千行を選択しているとすると、テーブルZからAまでの移動にはかなりの時間がかかります。
基本的にはあなた次第だと思います。テーブルを正規化しておくことが重要な場合は、非正規化しないでください。クエリの速度とメモリ使用量がより重要な場合は、テーブルを非正規化する必要があります。
お役に立てば幸いです。