Question

Reading about database efficiency I’ve stated that table indexes imposes extra costs to insert/update/delete operations.

That’s not a problem when dealing with a single record, but it can be when many records are implied.

I have several apps where I use SQL Server as DBMS and where I’ve added import operations that allows users to load several records into the business model in a single operation instead of having to manually fill a form for each record.

Now my question is: is a good practice in SQL Server to disable table indexes before the import operation is performed? Could this depend on the number of records or the volume of data involved in the operation? Are there any sidekick problems related to this practice that I must be aware of?

Answer 1

It depends on

• how many rows you need to import,
• how often you need to import,
• how long the import takes, and
• how many other people are affected.

When you drop indexes, you drop them for everyone. So every query against the affected tables will run without indexes until you rebuild them.

Dropping indexes can make a big difference when you’re importing millions of rows. But if it affects other users, I wouldn’t drop indexes until it was abundantly clear that there was no other practical way to get the import done. You might be able to avoid affecting other users by

• importing fewer rows at a time (more transactions),
• importing into a staging table first, or
• queueing imports to be done during off hours.