2009-04-26 9 views
3

私は中規模ビジネス用のイントラネットシステムを設計しています。すべてのモジュールに対して1つのログテーブルを保持するのか、またはそれを別々にするべきですか?モジュール用の単一の集中ログテーブルまたは分離ログテーブル?

監査ログはすべての管理/スタッフの活動(作成、更新、削除オブジェクト)を保持し、ログ構造はあらゆる種類のモジュールで共通です。

また、ログレコードに基づいてレポートを作成するとよいでしょうか?私のログテーブルはオブジェクトタイプとオブジェクトIDを保持しているので、任意のオブジェクトのデータをいつでも取得でき、イベント、オブジェクト名、オブジェクトIDに基づいていつでも取得できます。

このような場合には、どのような方法でレポートするのが最適ですか?

答えて

2

ログを確認するには、すべてを見たり、いくつかの場所を確認したりしなければならない場所を見てください。

テーブルが1つの場合、関連性のないエントリや表示権限がないエントリをフィルタリングするのは簡単です。いくつかの個々のログを1つの包括的なビューにまとめるのは少し面倒ですが、ほとんどの設計では、新しいログテーブルを追加するたびに結合を行うコードを再訪する必要があります。

私は間違いなく1つのログが望ましいと言います。複数の分離されたログが適切であると考えることができる唯一の状況は、異なる視界のログエントリを物理的に分離する必要があるほどセキュリティの懸念が強い場合です。このような場合、おそらく別々の別のテーブルだけではなく、ログサーバー。

3

log4phpを参照してください。 log4jは、ログの階層とレベルを導入することで、多くのログの問題を解決しました。私はlog4phpがどれだけ良いかわからないが、それは初心者にすべきだ。

3

私は1つのテーブルを言うでしょう。

たとえば、(わかっていれば)すべてのモジュールでユーザーアクティビティを見つけたいと思うかもしれません。 1つのテーブルに役立つ。

ログテーブルをオフにすることは問題ありません。別のレポートデータベースにオフロードして、競合を減らし、ロギングテーブルに負荷をかけます。

最後に、オブジェクト名と型を明示的に(データベースオブジェクト)保存します。 DROPとCREATEを実行すると、IDが変更されます。あるいはテーブルがビューになるかもしれないので、タイプとオブジェクトIDの両方が変更されます。

1

私たちは単一のテーブルを使用しており、特にパフォーマンスにおいて最適なソリューションであることが証明されています。特に大きなデータセットの場合既製のソリューションに興味がある場合は、thisを試してみてください。

関連する問題