2012-02-20 8 views
2

ユーザー、都市、アイテム、購入など多くの関連テーブルを持つスキーマがあるとします。現在、社内サポート用のイベントログデータのみを含むテーブルがデータベースに必要です。ロギングテーブル内の情報の行は自己完結型であり、すべてのリレーショナルではなく、他のテーブルとは無関係です。既存のスキーマに新しいテーブルを作成するか、まったく新しいスキーマを作成する方が良いでしょうか? 1つの方法が他の方法よりも優先されますか?それに伴ってコストがかかりますか?新しいテーブルと新しいスキーマ

+0

何百万行もログを記録しておらず、データをオフロードするために別のデータベースサーバーが必要な場合を除き、私はそれを分割する正当な理由は見当たりません。後でパフォーマンスの問題が発生する場合は、別のスキーマにテーブルを移動することができます(説明に従って)。 – bumperbox

+0

あなたは本当に "無関係"を意味しますか?ロギング情報は他のデータとは何の関係もありませんか?別々のアプリケーション? – ninesided

+0

データが別のサーバー上にある必要がない場合でも、行がダウンする可能性があり、最初からその分離を行う方が簡単なので、別のスキーマを使用します。ロギングシステムのスキーマ定義が、既存のスキーマ名定義とは独立して定義されていることを確認してください。後で新しいスキーマに移動する場合は、変数のロードを変更する必要はありません。 –

答えて

0

私の意見では、データが無関係であれば、それは別のスキーマに属します。単一のスキーマにすべてを持たせるのではなく、新しいスキーマを作成する際のオーバーヘッドが非常に小さい可能性がありますが、気にする価値はないと思っていました。

1

私の意見では、すべてあなたのデータベースのサイズに依存します。何百万行ものデータを持つ数十のテーブルを管理している場合は、これらのロギングテーブルを独自のスキーマ/データベースに分離して管理することが容易になります。あなたがちょっとしたアプリケーションを管理しているだけなら、すべてを1つのデータベース/スキーマに入れても構いません。データベースが大規模であるか、またはデータベースが大規模になることが予想される場合は、それらを分解してください。それらが別のエンティティに分割されると、あらゆる種類の優れたツールを使用して、複数のデータベース/スキーマ間の通信を簡単に管理できます。

関連する問題