Want to see both the older as well as new updates made to any field of a Record

I recommend a history CDT. Everytime a value is changed at the same time you store the change there.
I recommend the following structure of the history CDT.

• ID (PK)
• the table/cdt name,
• primaryKeyInTable/Id,
• fieldName,
• old value,
• new value,
• timestamp 
• changedBy 

I typically use Richard's solution when implementing "Change Log" type of functionality.  A big helper to this is the CDT Diff Utilities plugin which can compare 2 CDTs and give you a listing of fields which have changed, their old and new values, to help you more easily log the change, vs having to code field by field.

Otherwise another method would be to have a full log table, which is a essentially a copy of your primary table.  In this log table, the PK of the parent table is not a PK (it can be entered multiple times), and you have a new PK field specific to the log row.  At any rate, when you are persisting your primary CDT, copy the row into the log table CDT and write that as well, which will create one entry in the log per save of the main data.

There are a few additional considerations, but I'll include those in the overall approach I am thinking of taking for my current project:

1. you need to be able to tell what has changed between two different states of your data. For this you'll need:
   1. two copies of the data - the 'before' and the 'after'
   2. a means by which to determine those differences - this is why I created the CDT Diff Utilities in the first place
2. you'll need to exclude those data items that are "meaningless" to an end-user. All entity-backed data will have Primary Keys. These by definition will be different between two different instances of the snapshot data. So you need a method toi identify these and to suppress them from any presentation to an end-user
3. you need to make the presentation to the end-user meaningful i.e. you can't just use the attribute names. So the solution needs to include a "look up" method that will translate the attribute name to a meaningful business name. If you're lucky enough (like we have been on our project)  to have had to implements Internationalization you can use the Bundle file "key" as the mapping to the attribute value and thus provide a maintainable way of presenting the data
4. Depending on your requirements you may also need to handle how the actual data values need to be rendered e.g. if the attribute is of type date you may be required to identify that it's a date and present it in the UI accordingly.