Identity is hard. If you assign an integer to every row, as the article suggests, you have to decide how that integer is effected by update operations. If the r

Identity is hard. If you assign an integer to every row, as the article suggests, you have to decide how that integer is effected by update operations. If the reference is by identity (ie the new row gets the same id) then you have to worry about stability of ids in materialised views (eg if some part of the view is recalculated how we decide whether the new rows are altered versions of the old rows or brand new rows). If the reference is by value (ie new rows always get new ids) then you will need some separate way of assigning identity to entities which don't have a natural primary key (eg users). The data model I'm currently working on is an append-only event log with incrementally maintained views. Since we don't have to worry about update to the base rows I'm leaning towards having references be by value and relying on the maintenance algorithm to ensure that changed ids are propagated nicely. In cases where actual identities are required they will need to be supplied in the event log so that they are stable (eg user signup messages must contain enough unique information to create an id for that user). I haven't been able to dig up much research in this area so I'm all ears if anyone has any thoughts.