, evildictait​or wrote

*snip*

Wait ... you were going to give SQL creds to every user of your software? (or worse - have no authentication to the SQL server!?) Have you heard of computer security?

Set up a HTTP service. That way you're abstracting your app from the implementation of the database, you get to perform user-based authentication later and you can limit people's ability to root your SQL server and take all of your company's information.

SQL is dangerous. Don't let users (even users from your own company) write their own.

  1. He didn't say users were going to write their own SQL.
  2. You're one size fits all approach still isn't the right fit for everyone.  I have a desktop application that downloads public data from the internet and stores it in a local database for analysis (mostly pre-developed reports but also has an ad-hoc feature).  It does not make sense for me to have a central server for this because the app is free, the central service would be too expensive being that the app is free and the range and size of data plus the frequency of load would by intensive as the user base expands.  However, it's perfect for SQL Express or SQL Compact running locally.  Let's assume SQL Compact.  They can now cache their data offline and use it as needed.  It is leaps and bounds faster running off of this than relying on delivery of large amounts of return data over HTTP.  Security wise, what are they going to do... decompile my app, tinker with the dynamic SQL generation methods and wreak havoc on their own SQL Express/Compact instance?  So what if they do, it's a local database with non sensitive data in it.  Have at it.

Now, that said, I'm not saying using a middle tier HTTP service is bad by any stretch of the imagination.  On the contrary, it's a great idea in a lot of cases.  Just not 100% of them.