created_at vs meaningful db column name , or both? I need often to store the datetime of an action.
For example, for a customer order, "processed_at" would be a right name.

However I need all my tables to have a created_at/updated_at fields for several reasons, among other data export (some ORM generate even the created_at/updated_at by default).

If I use created_at as standard, I wouldn't need the processed_at field as they will be the same, but in such a way I'll lose the "meaning" of the field.

But if use processed_at I'll have to customise all data export based one the relevant "_at" field.

I could create both...storage is not so expensive after all.

Just curious, what have you seen around?
If you're setting a standard that all tables need a column_x, then the standard columns need to be... well... standard. The only way for the columns to be generalisable sensibly in the way you describe is to have created_at be metadata about the record and not the data for the row. processed_at is a different, separate data point that says something about the external world. If you hijack the created_at because it has a reasonably similar name then you've de-standardised the usage of that column - at which point why bother adhering to the standard rigorously? Just name each column what it is.


  TL;DR: use both if you need the standard columns to support your ORM. Don't hijack created_at for non-metadata