Drop constraints vs disable constraints during a data import

Question

I am in a tough situation, and looking for advice on how to proceed. I have to import some data from one environment to another. 80% of the records have been modified, so the plan is to simply delete all the existing records, and import the new ones.

Unfortunately this is a base table. Several other tables have FK's defined, pointing at this table. In order to delete the data, I need to either drop the FK's and recreate them when finished the import, or disable the constraints and re-enable them.

No records have been deleted. A copy of prod was made, and developers have tweaked the data and added new records.

Which approach would you take?

Answer 1

As recommended by Mikael Eriksson, I'd do the import without dropping/disabling the Foreign Keys.

The downside to this is if you want to delete any records who's values are referenced by an FK or want to update values such that the original value is no longer in the table and referenced by an FK.
In these cases you'd need to keep track of any such issues and decide how to handle each "conflict" (don't update/delete, alter the data in the other table or some other solution).

This will be quicker, easier and ensure data integrity compared to dropping/disabling the FKs, importing and then restoring the FKs.