[arialdomartini]

While I like the YAGRI principle very much, I find that adding

- updated_at

- deleted_at (soft deletes)

- created_by etc

- permission used during CRUD

to every table is a solution weaker than having a separate audit log table.

I feel that mixing audit fields with transactional data in the same table is a violation of the separation of concerns principle.

In the proposed solution, updated_at only captures the last change only. A problem that a separate audit log table is not affected to.

[grey-area]

An audit log table often takes a huge amount of space compared to simple fields on the records so there are tradeoffs. Which solution is best depends on how important change logs are.

[wodenokoto]

I kinda agree, but don’t underestimate the power of having things where people are looking.

Put your documentation in doc strings where the function is defined - don’t have a separate file in a separate folder for that. It might separate concerns, but no one is looking there.

Similarly if those fields aren’t nullable, someone trying to add new rows will have to fill in something for those metadata fields - and that something will now very likely be what’s needed, rather than not pushing anything to the audit table.

Obviously your app can outgrow these simple columns, but you’re getting value now.

[motorest]

Event sourcing also works great. You don't need an audit log per se if you already track a history of all commands that introduced changes to your system.

[nine_k]

Event sourcing and "the right to be forgotten" are not always easy to marry.

[arialdomartini]

Yep. But Event Sourcing comes with its own set of other problems. Also, I don't think this would apply to OP's post: with Event Sourcing you would not even have those DB tables.