Une seule table de bûches centralisée ou séparée pour les modules?

Question

Je suis en train de concevoir un système intranet pour les moyennes entreprises. Devrais-je conserver une seule table de journal pour tous les modules ou la séparer? Le journal d'audit conserve toutes les activités admin/staff (créer, mettre à jour, supprimer des objets) et la structure du journal est universelle pour tout type de module.

Et est-ce aussi une bonne idée si je tire un rapport basé sur les enregistrements de journal? Ma table de journalisation conserve le type d'objet et l'identifiant de l'objet afin que je puisse récupérer des données pour n'importe quel objet et à tout moment en fonction de l'événement, du nom de l'objet et de l'identifiant de l'objet.

Quelle est la meilleure approche pour les rapports dans de tels cas?

Answer 1

Eh bien, quand vous allez examiner vos journaux, que préférez-vous faire, regardez dans un endroit où vous pouvez tout voir ou avoir à vérifier plusieurs endroits différents, dont chacun montre juste une partie du système en isolation? Gardez à l'esprit que, avec une seule table, il est trivial de filtrer les entrées qui ne sont pas pertinentes ou que l'utilisateur n'a pas l'autorisation de voir. La combinaison de plusieurs journaux individuels en une seule vue complète est un peu plus compliquée à réaliser, et présente l'inconvénient supplémentaire, sous la plupart des conceptions, de revoir le code qui effectue la combinaison chaque fois qu'une nouvelle table de journal est ajoutée. Je dis vraiment qu'un seul journal est préférable. La seule situation à laquelle je pourrais penser lorsque plusieurs grumes isolées seraient appropriées serait si les problèmes de sécurité étaient suffisamment importants pour exiger que les entrées de journaux ayant une visibilité différente soient physiquement séparées - et, dans un tel cas, vous étudieriez probablement serveurs de journaux, pas seulement des tables séparées.

Answer 2

Voir log4php. log4j résolu la plupart des problèmes de journalisation en introduisant la hiérarchie des journaux et les niveaux. Je ne sais pas à quel point log4php est bon, mais ça devrait être une entrée.

Answer 3

Je dirais une table.

Vous voudrez peut-être trouver l'activité de l'utilisateur sur tous les modules, par exemple (si je comprends bien). Ce qui se prête à une table.

La création de rapports sur votre journal serait OK. Vous déchargez dans une base de données de rapports distincte pour réduire les conflits et charger sur la table de journalisation.

Enfin, je voudrais stocker le nom et le type d'objet explicitement (objets de base de données). Si vous déposez et créez, l'ID changera. Ou une table peut devenir une vue par exemple, à la fois c'est type et objectid va changer.

Answer 4

Nous utilisons une table unique et il s'est avéré être la meilleure solution, en particulier dans la performance. Et surtout avec de grands ensembles de données. Si vous êtes intéressé par une solution prête à l'emploi, essayez this.