Table triggers will kill your performance and are generally frowned upon. If your database is small and your users are few it won't matter, but this isn't a scalable...

We maintain "TableName_deleted" tables for our data tables, each of which is the same structure as the data table it reflects (except for no key fields), plus one field...

pretty much the first google hit

https://www.mssqltips.com/sqlservertip/2552/creating-an-ssrs-map-report-with-data-pinpoints/

Granted, restoring a backup to a live database after a deploy with issues is risky at best and virtually impossible in most cases. Typically we just move forward because...

SQL uses statistics to check ordinality and cardinality of a table to figure out which index to use or which query plan to use.

if your data changes in volume in...

I think jeff might be onto something - as soon as I started reading his message I had the words "parameter sniffing" popping up

index hints is also a valid tool...

We use synonyms a lot between databases so we can keep the general functionality separate and give us lines of demarcation for all sorts of things including the isolation...

best of luck - if you have the chance, try both methods, ignore us all and go with the one that best suits you

I'm now curious as to the original poster's opinion - thankfully no-one has posted "mirror with snapshot" or "log shipping"

First, if your developers have the ability to delete data from a production database, it's not a production database, it's a development database. There's no excuse for letting developers...

Replication uses has far more headaches than a simple linked server.  I'm not against replication when it's really needed, of course, but I don't see that need here.  I,...

when I worked as a test...

In my current role, Scripts are executed by the Release Team, so it's difficult to hand them something that requires input e.g. changing the @doCommit value to commit the...

Interesting point, part of the devops process is about automated builds (including stopping people developing...

good shout. worth looking into. I think our data churn is way too big for that...