Background A discussion that has come up at work recently is how we handle audit
ID: 643872 • Letter: B
Question
Background
A discussion that has come up at work recently is how we handle audit logging and the recording of events. We are integrating with a 3rd party app so triggers are a no no from the off so we are handling it in code. We've written a number of prototype components for handling it but nothing feels right as yet. The main issue being we want to create Facebook style time lines for the users to see what action have happened recently but these don't seem to fit well with how we record audits.
My question is how would be best to handle this type of scenario?
Should we tailor the audit log tables to fit the requirements of the front end?
Should we have separate tables to handle the "Actions" and have the events and auditing separate
Should we look to a more message based architecture so this will be more like an Event sourcing type component?
Input from somebody who has done this type of system would be much appreciated.
Explanation / Answer
Should we tailor the audit log tables to fit the requirements of the front end?
No. Generally this is better when you tailor the audit log tables to fit the requirements of auditors and then worry about the front-end later.
Should we have separate tables to handle the "Actions" and have the events and auditing separate
Yes. This gives you more control over events, and adding new ones as you need.
Should we look to a more message based architecture so this will be more like an Event sourcing type component?
I prefer to keep things simple and merely store in the db. However a message-based architecture may work well if you are integrating into a multi-tier application and your code is somewhere in the middleware. But here it depends on what you need and we'd need to talk more specific requirements than we have here.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.