Here's a real world example if you run a script once every 5 minutes that launch sub-task you might be tempted to add a non natural auto-increment number that identify each occurence to create a link between the script and the subtasks.
However it will be way more painless to use a timestamp of the script starting point a natural key.
This way when shit happen you have a relevant and stable way to identify each occurrence. And timestamp is easily indexable and ordered.
If you want a timestamp, by all means add a timestamp field. And of course add a (non primary) key on the field.
I would add a different surrogate field though for the primary key. Because I've -always- discovered edge cases which break my original model.
In this situation I can think of 2. Firstly if the process triggers twice at the same time you have a problem (which happened to me in a case where a test suite fired up thousands of instances on a machine with many cores). Secondly twice a year with daylight savings (and when the owner of the system decided to change from local time to utc).
Is there an actual natural kh out there that will never fail me? Probably. But I'm tired of looking for it.
So use timestamps with sub-second precision, which virtually every SQL database supports (even ones like SQLite that don't have built-in date/time types).
However it will be way more painless to use a timestamp of the script starting point a natural key.
This way when shit happen you have a relevant and stable way to identify each occurrence. And timestamp is easily indexable and ordered.