web-dev-qa-db-ja.com

1つの大きなテーブルといくつかの小さなテーブル

以下の例は単なる例であり、私のシナリオはもっと複雑であり、私がそれをモデル化しようとしている方法は本当に理にかなっていることに注意してください

アプリの1つで監査イベントのテーブルを作成しているとしましょう。「event_created」、「user_created」などすべての種類のものです。テーブルにはいくつかの列が含まれており、それらのいくつかは他のテーブルへの外部キーです。時間の経過とともに、この単一のテーブルは数百万のレコードに成長する可能性があります。

パフォーマンスの観点から、それらすべてに単一のテーブルを使用するのか、またはイベントの種類ごとに個別のテーブルを使用して個別のテーブルで操作するのがより速く、より高性能ですか?それともそれほど違いはありませんか?イベントの種類ごとに個別のテーブルを作成するのはばかげているように聞こえるかもしれませんが、私の現実のシナリオでは、それは本当に理にかなっていると私を信頼する必要があります。

4
mbajur

最後の手段としてのみ非正規化

架空のパフォーマンスの問題のために、テーブル設計を 非正規化 しないでください。 時期尚早の最適化 に陥らないようにしてください。

適切な構造を設計します。偽のデータを生成してテーブルに入力します。展開シナリオに類似した状況でテストを実行します。重大なパフォーマンスの問題が証明された場合:

実証済みのパフォーマンス問題を修正するための手段をすべて使い果たした後でのみ、非正規化を検討する必要があります。

Postgresは強力なエンタープライズ品質のデータベースシステムです。十分なRAMおよび最新のハードウェアで数百万行があり、賢明なインデックス付けはまったく問題ありません。

一方、異なるタイプのイベントが異なるエンティティを表す場合、それらは別々のテーブルに保持する必要があります。類似した種類の行が異なるエンティティであるかどうかをどのようにして知ることができますか?手がかりは、「セマンティクスが同じでほとんど同じ列を持っていますか?」ユーザーが一緒に表示またはレポートしたいと思ったことはありますか?一緒に集計(カウント、平均、中央値などを計算)したいと思ったことはありませんか?

コンピュータハードウェアの機能と構成が今日のハードウェアよりもはるかに制限されていた時代にさかのぼる長い歴史を持つ製品として、Postgresのデフォルトの設定はかなり保守的です初期インストール時。たとえば、デフォルトでは、Postgresは古い Raspberry Pi !したがって、より高性能なハードウェアでより大きなデータベースを実行している人は、何らかの調整を行う必要があります。

10
Basil Bourque