The question can be summarized as:
In a database (regardless of type), would it be considered a good practice to always include
updated
,created
(and possiblydeleted
) properties, for all entities, regardless of nature?The question is asked in the abstract, but I'm looking for real life answers, common - and hopefully good practices here.
Is there a name for this convention?
In real life applications, data often stands at the core of a service. The data is what's of importance, the rest of the application is just various ways of presenting that data. I'm speaking mostly from the perspective of a web-developer, seeing as it is the industry I work in.
More often than not can logging and tracking of data be more important than the payload it carries, i.e.; it's OK to trade of a few bytes of bandwidth and disk-space for knowing when this 'hunk of data' last got updated. Having persistent data, is also commonly of great importance (speaking mostly for the deleted
-property here). As knowing when something was deleted, is often always better than having... "a few missing ID's" in a table, at most. - You do of course, save some disk-space.
Bandwidth and storage are getting real cheap, just googling cost per gigabyte over time and similar for bandwidth; pretty much speaks the same language. Transferring and storing data is cheap and it is getting cheaper.
Some databases even roll with a time stamp as part of the ID, I'm speaking of course of MongoDB, although they were probably not the first to traverse this area.
Keeping the previous things in mind, would it be a 'bad idea', to implement a policy/practice to always persist data and to always implement 'auto-updating' (if possible) created
, updated
and deleted
properties?
accessed
which has been extremely useful in the past. – Jerry Jeremiah Jun 21 '16 at 19:49