セッション/ログテーブルのキー設計の質問

Question

私はたいていの場合、ユーザーセッションやログテーブルでFKを使用しないと言っていると聞いていますが、通常は高書き込みテーブルであり、書き込まれたデータはほとんど常に更新や削除がありません。

しかし、問題は、私はこれらのようなcolunmsを持っている： USER_ID（ユーザーへのセッションやアクティビティログへのリンク） ACTIVITY_ID（システム・アクティビティ・ルックアップ・テーブルにログアクティビティテーブルをリンク） SESSION_ID（ユーザログテーブルをリンクします親セッションで） ... 4〜5個の列があります。

FKを使用しないと、これらの列はどのように「関連」しますか？テーブルに参加してFKなしでユーザー情報を取得できますか？ FKなしで正しいデータを書き込めますか？どんなパフォーマンスに影響を与えるのか、それとも人々はちょうど話し、これはいいえではないと言いますか？

---

FKを使用しないと、データをルックアップテーブルに接続することはできますか？

Answer 1

実際、mysqlで実際のFKを持たないデータベース全体を構築することができます。 MyISAMをストレージエンジンとして使用している場合、FKは実際には実際ではありません。 それにもかかわらず、結合キーが一致している限り、好きなすべての結合を行うことができます。

パフォーマンスへの影響は、参照するテーブルにどれだけのデータを格納するかによって異なります。テーブルにFKを入れてデータを挿入したり、FK値を更新したりする場合は、余分な時間がかかります。挿入または変更の際、参照整合性を保証するために、参照されたテーブルでFKを参照する必要があります。

参照整合性を必要としない高度に使用される表では、FKの代わりに緩い列を使用します。

AFAIK InnoDBは現在、（MySQL 5.5にもサポートされている新しいまたは更新されたストレージエンジンがない限り）実際の外部キーをサポートする唯一のものです。 MyISAMのようなストレージエンジンは構文をサポートしますが、実際には参照整合性を検証しません。

Answer 2

FKは、「履歴ログ」テーブルに有害な可能性があります。この種のテーブルは、ある時点で起こったことの正確な状態を保持したいと考えています。

FKの問題は、値を格納することではなく、値を指すポインタだけであることです。値が変更されると、履歴は失われます。あなたは履歴ログにカスケードする更新をしたくありません。あなたが参加できる「偽の外部キー」を持つことはOKですが、ヒストリを保持するために関連するフィールドを意図的に非正規化したいこともあります。