In the project I’m working on, audit log also started from the very minimalistic design, like the one you described:
event ID event date/time event type user ID description
The idea was the same: to keep things simple.
However, it quickly became obvious that this minimalistic design was not sufficient. The typical audit was boiling down to questions like this:
Who the heck created/updated/deleted a record with ID=X in the table Foo and when?
So, in order to be able to answer such questions quickly (using SQL), we ended up having two additional columns in the audit table
object type (or table name) object ID
That’s when design of our audit log really stabilized (for a few years now).
Of course, the last “improvement” would work only for tables that had surrogate keys. But guess what? All our tables that are worth auditing do have such a key!