In the first case, you only know the AMOUNT. You can't undo transactions because you only have 1 object stored, the total amount. If you store DIFFERENCE, then you'll have a table of every transaction and can undo them individually. The cost is having to sum the table whenever you want to know the amount (which is usually worth the flexibility).

Regarding the performance - you can add triggers writing to additional table with a sum, or maintain that table in the code that adds rows, or calculate it each time you want to know the sum.

This is what I understood (s)he means

Scenario: Laptop's price is initially $800 and then increases to $850 before dropping to $825

Design 1: with columns Amount and Kind will just have a single row which will get modified with the latest value

Design 2: Will have 3 rows in the above case

Difference | Kind | Time stamp

800 | 'Laptop' | ts 1

+50 | 'Laptop' | ts 2

-25 | 'Laptop' | ts 3

So this latter design has 'undo' builtin

edit: formating

Yes, that's what I've meant. This also gives you easy accountability (rows can have information like user_id, ip, timestamp).