My DB has about 90 tables. Most of the tables have an UpdatedBy and AddedBy column that have foreign keys pointing back to the user table. With even moderate amounts of data spread throughout the database, this makes for a very slow delete process when purging old user records.
Our delete query first updates all of the Updated/Added references to the current user and then deletes the user record. The execution plan shows table scans for each related table due to the foreign key. See this post as an example of what we are facing.
The pointers back to added and updated are not really useful other than for analysis during application problems. They are rarely used, and aren't a primary source of good information when they are. I'm wondering if I should remove the foreign key constraints all together or if I should possibly move the auditing of updates to a separate table that keeps a record of table name, column, value, and user id, or if there is some other generally accepted approach that the DBA community gravitates toward for this sort of situation.
NULL
, then ran theDELETE
. Yes, this is two write operations for each row, but may turn out to be less expensive than any checks involved with the FKs when the values are present... particularly if you delete the rows in batches. It is moving swiftly toward the end of a long day, and I'm not sure what I'm suggesting actually makes sense, but it seems obvious that the constraints are having an effect on the duration of the transaction, and if the referencing value isNULL
it may help.