(1) Assuming there is a primary key on table A, have a table recording only those primary keys in table B. When the application starts up, check for rows in B that are no longer in A to get deleted rows. (Vice-versa will get you new/inserted rows.)
(2) Row version (combined with the above) is indeed ideal for what you want. Failing that, some from of checksum might be used. MS SQL Server as the CHECKSUM()
function, which can be used to produce a hash value based on the contents of the entire row of data. (While hash values cannot be guaranteed to be unique, they should suffice, particularly here since you'll be checking both the hash value and the primary key value, where the primary key will be used in the hash calculation.) Upon application startup, calculate the hash value for all existing rows in table A, and check them against the tracking table created above:
- If primary key in new set not found in B, it's a new row, insert primary key and hash value
- If primary key in B not found in new set, it's a deleted row, delete
- If primary key found in B and in new set and hash value differ, row has been updated, process accordingly
- If primary key found in B and in new set and hash value match, row has not been updated
Sadly, I suspect implementing the above might not save you that much time, since table A will still require a full table scan.