私の書き込みテーブルからすべてのFKを削除する

Question

私は非常に重い書き込み集中テーブル（ユーザ追跡テーブル）を持っており、ノンストップで書かれています。問題は完全に正規化されたスキーマにあります。16個の外部キーがあります。いくつかのキーは純粋にルックアップ参照のためのもので、いくつかはユーザーID、ユーザーセッションID、アクティビティIDなどをリンクするようなものです。

このように多くのFKが書き込み集中テーブルのパフォーマンスに問題があります。 （私はリアルタイムの更新に近い必要があるユーザーコンテンツのWebサイトを持っています）。だから私はこれらの集中的なテーブルを書くためにすべてのFKを落とすことを計画しているが、その前に私は他にどのように私がデータをリンクすることができますか知りたい？人々がコード内で言うとき、私たちがアプリケーション内で関係を持つことはできないと仮定して、データをリンクした状態に保つためにコードレベルで正確に何をしていますか？

第2に、FKを使用しないと、corect IDが書かれている限り、データはまだ一貫していると思いますか？何らかの理由でFKが使用されていない場合、メンバーIDが2000の場合と違って3000を書き込むでしょうか？

最後に、これは正しく結合に影響しませんか？私は結合を避けることを望みますが、私はいくつか必要とするかもしれません。しかし、私はFKsまたは結合されていないと仮定することができますか？

Answer 1

Secondly, if I dont use FKs I assume data will still be consistent 
as long as the the corect ID is written? 

はい。

Lastly, this will not effect joins right? 

右。

When people say in the code, what exactly are we doing at the 
code level to keep data linked together 

これは本当の質問です。実際には実際にはの2つの質問があります：

1）入力値がすべて有効であり、確認する必要はありません。

2）ルックアップテーブルはどれだけ参照されていますか？

答えが「あまり確信していない」と「本当に小さすぎる」場合は、アプリ層の回答をキャッシュし、挿入する前にこれらの超高速インメモリテーブルを使用してルックアップを行うだけで、しかし、これを考慮すると、データベースも小さなテーブルをキャッシュするので、fksを維持するのは依然として簡単かもしれません。

答えが「あまりにも自信がありません」と「本当に巨大な」場合は、選択肢があります。 FK制約を削除したり、故意に不正な値を挿入したり、ポストジョブのクリーンアップを行うことができます。そうしないと、その不良データがすべて失われる可能性があります。

この組み合わせでは、アプリケーションでテーブルをキャッシュするのは実用的ではありません。アプリケーションからテーブルを削除してルックアップを行うと、データベースにfkがあるよりも速度が遅くなります。

回答が「100％信頼できる」場合、2番目の質問は重要ではありません。 fkを落として、速度と信頼度でデータを挿入します。