some observations :

Method 1 suggests, just anonymising the incremental updates and adding it to the table, this could over-generalise the incremental data hence lose data quality → BAD IDEA

Thus any incremental data must be added to the entire database and then the anonymisation technique must be applied

Thus, the major drawback of the approach anonymizing incremental updates is twofold: it over generalizes the incremental updates, and cannot use the incremental data to reduce the information loss in the anonymization of the existing data.

Interesting paper, talks about incremental insertions in a dataset and how k -anonymity is maintained at every release of the incremental additions of the data

Releases F(T), F1(T ∪ ∆T1), F2(T ∪ ∆T1 ∪ ∆T2), . . . are k-anonymous against incremental updates if the following three conditions are always satisfied. (1) F(T) is k-anonymous; (2) for each i ≥ 1, Fi(Ti), the re- lease after the i-th incremental update, is k-anonymous; and (3) for each nonempty set of positive integers {i1, . . . , in}, I(Fi1 (T1), . . . , Fin (Tn)), the inference table using the re- leases, is still k-anonymous.

Most specific information from all releases is called the inference table

All the tables must maintain k-anonymity, this is a better method than ensuring the generalisatio level of a tuple is always greater than the current generalisation level, can get very difficult to track