![]() |
| Time for an audit! |
Take for example this schema in MySQL, for the table Members.
CREATE TABLE Members (
"id" INT NOT NULL AUTO_INCREMENT,
"name" VARCHAR(100) NOT NULL,
"createdAt" DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
"createdBy" VARCHAR(50) NOT NULL DEFAULT "system",
"updatedAt" DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
"updatedBy" VARCHAR(50) NOT NULL DEFAULT "system"
);
"id" INT NOT NULL AUTO_INCREMENT,
"name" VARCHAR(100) NOT NULL,
"createdAt" DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
"createdBy" VARCHAR(50) NOT NULL DEFAULT "system",
"updatedAt" DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
"updatedBy" VARCHAR(50) NOT NULL DEFAULT "system"
);
The last four fields are Audit Fields:
- createdAt: this is a timestamp that is set to the current date and time when the record is created, and never changed.
- createdBy: this is a string that is set to the user's login when the record is created, and never changed.
- updatedAt: this is a timestamp that is set to the current date and time when the record is created, and changed to the current date and time every time the record is updated.
- updatedBy: this is a string that is set to the user's login when the record is created, and changed to the current user login every time the record is updated.
How do Audit Fields work?
"Created" fields. These are less useful because they should never be updated, and serve as a static record of when the record was created, and by who. However, it's good to have because it provides an initial reference point to troubleshoot if needed.INSERT INTO Members (name)
VALUES ("Ally Gator");
VALUES ("Ally Gator");
| id | name | createdAt | createdBy | updatedAt | updatedBy |
| 1 | Ally Gator | 2024-05-05 16:05:42 | admin1 | 2024-05-05 16:05:42 | admin1 |
"Updated" fields. These are updated when the record is created and every time the record is updated. While it's not as useful as a full audit log, it at least lets you know when the last update was. Let's say you run this query.
UPDATE Members SET name = "Allie Gator" WHERE id = 1;
| id | name | createdAt | createdBy | updatedAt | updatedBy |
| 1 | Allie Gator | 2024-05-05 16:05:42 | admin1 | 2024-05-16 12:27:21 | admin1 |
Why Audit fields?
At the risk of stating the obvious, these are useful when you need to perform an audit (hence the name) on a database as to what records were created or updated, when, and by who. The importance of this only becomes increasingly obvious the larger the database grows.Audit Fields can be a pain to set up, especially if you're not used to it. Once you've done it enough, though, you may find yourself wondering how you ever managed without them. Yes, they take up space. Yes, you have to bear them in mind during INSERT and UPDATE operations.
But man, they're awfully useful.
![]() |
| Examining data. |
Imagine you need to do some forensics on some data that got added out of nowhere. You can check the timestamps and the ids of whoever created them. If they don't match any user on record, you know you have a problem. Scratch that - there's (almost) always a problem, but at least you have a better idea where it's coming from.
Or even if it's not a security breach, perhaps there's a dispute as to who was responsible for a certain data update? If the timestamps and user ids are right there in the database, there's instant accountability.
And all this is not even considering the fact that depending on the prevailing laws of the land, the presence of Audit Fields may even be mandatory.
Ultimately...
Get comfortable with the concept of Audit Fields. It's not new. It's pretty much timeless, in fact. It always represents some extra work at the start, but will save you so much hassle in the long run.See you later, Allie Gator!
T___T
T___T
















