If you use replication, you have had the situation occur where you had to restore a replicated database. You’ve have doubtless been paged to restore a replicated database. You have experienced the ineffable joy of being tearing down replication-dependent indexed views (if you have them), blowing away replication, doing the restore, putting replication and indexing back together again, and finally redeploying your indexed views. I know I have.
In fact, I’ve done it enough times that I didn’t want to do it anymore. So, you may ask, did I go to a different modality of replicating my data? Did I go to Availability Groups or mirroring instead? No. I actually like replication. It’s invaluable when you need to write code around real-time data (especially from a third party database), but you aren’t able to index the original copy. It’s been around for a long time and is well vetted, and pretty forgiving, once you understand how it works. So, no need to reinvent the wheel. I decided to automate replication instead.
This is specific to transactional replication. There’s a whole ‘nother kettle of fish for merge replication.