james_anderson

Do you find yourself in the difficult position of having users who make updates to the database owned by your application?

In my experience this happens because the application has gaps in functionality or the process would be much faster to complete in SQL then it would in the app. This makes turning off access difficult as these processes are often business critical.

Problems caused: - Short-term - people make mistakes and corrupt/destroy data or cause downtime. - Long-term - data can't be trusted.

I'd be interested to hear people's war stories and the methods/tech used to escape.

My thoughts are: 1. Track scripting 2. Catalogue reasons for scripting 3. Address the functionality gap that will remove the most common reason for scripting 4. Remove access to tables users were updating via SQL before functionality gaps were filled 5. Continue 1-4 until done

I'm really interested to know if anyone is doing this, why they chose to do this and how they are getting on with it.

I've been thinking about this recently and what would be involved. Some of my thoughts / ideas are listed below.

Would need orchestration, probably K8s Windows containers or Linux containers? Possible to scale out reads by dynamically adding Always On Availability Group read-only replicas? Licensing would restrict large scale outs

SQL Server 2017 has been announced and the big feature is cross platform.

I'm wondering how many Linux people out there would consider running SQL Server on Linux in a production environment. If not, why not?

I can guess some of the reasons people will site but I expect there are many more.