問題はあまりありませんが、ベストプラクティスと今後の私にとっては何が問題になるでしょうか。データベース設計における外部キー
私は私のスキーマ内のアカウントにリンクされているデータが含まれているテーブルの数いる- などのサービス、場所、プロバイダ、
が、私は2つの選択肢があり、私はすべてにアカウントへの外部キーを追加することができます私のテーブルは必要な結合の数を減らしますが、格納されたデータに潜在的に追加され、不一致を招く可能性があります。
私の質問は、サービス、ロケーションなどにアカウントFKを追加するか、それを管理するためにジョインに頼ることですか？
データベースの構造を知らなくても、正しい答えを出すのは難しいです。しかし、例えばテーブルprovidersを1つ取ってみましょう。プロバイダが1つのアカウントしか持つことができない場合は、providersテーブルにFKを追加します。これが当てはまらない場合、私はFKを使用しません。なぜなら、それはうまくいかないからです。
外部キーは、物事を互いに関連付けて矛盾がないようにすることです。したがって、employeesテーブルとdepartmentsテーブルがある場合、employeesの従業員は1つの部門にしか属していないため、FKはdepartmentsになります。
あなたはFKのことを理解していて、それがあなたに何を与えているかわかります。
FKはPK（プライマリキー）を使用してテーブルに参加する必要があり、これによりテーブル間のデータの整合性が確保されます。
ただし、FKの列にインデックスを作成しないと、索引付けされていないFKになります。これにより、結合でフル・テーブル・スキャンが行われる可能性があります。
PKのものとFKのものは単なる制約であり、記憶に追加しません。 FKのインデックス作成はストレージに追加されますが、通常はインデックスのパフォーマンス上の利点がストレージのオーバーヘッドよりも優れています。
PKとインデックス付きFKを使用することはすべて正規化されたデータ設計の一部であり、使用には心配する必要はありません。
外部キーと結合の数は、互いに関係ありません。さらに、データの完全性を保証するために外部キーがあります。私はそれらの多くを追加することがどのようにデータの不一致につながるのか本当に理解していません。あなたの質問は本当に私には分かりません。 – Shadow
なぜ矛盾する可能性のある冗長データを持ちたいのですか？結合の数は実際には重要なメトリックではありません。パフォーマンスが懸念される場合は、標準化された設計をベンチマークし、インデックス作成で達成できるものを確認してください。 – reaanb
関連テーブルごとに 'SHOW CREATE TABLE'を提供してください。 –