dan-572483 (5/4/2015)
In the scenario you describe, if you shrink your database after deletes it will only grow again during inserts. The time it takes to do the shrink adds time to the process, as does the time to grow the file during the inserts.Then there is the matter of fragmented indexes from the shrink. Yes you can rebuild indexes, but that adds even more time & resource overhead.
So you are better off just leaving the database file at the larger size. Note that shrinking a database does not reduce the size of backup files. Backup file size is dependent on the amount of data in the data file, not the size of the data file.
The shrink and grow of a database leads to fragmented files in storage, not to fragmented indexes. Heck, we could just run a defrag on the indexes and fix the issue. No, this is fragmentation at the OS level.
Just a note. Everything else you say is right.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning