Excel should have a built-in, top-notch SQL editor/IDE. Existing SQL IDEs return resultsets in a grid, thus, Excel is a natural fit. Excel would allow developers to go beyond a SQL IDE by subjecting the results to the rest of the spreadsheet's functionality. Would work great for exploratory analysis or for production reporting.
Currently, running SQL and returning the results to a sheet is possible, but very cumbersome now: either .ODC files, VBA, or PowerPivot, none of which are flexible or developer-friendly.
It's not great, but there's an existing SQL IDE called Microsoft Query. You can find it in the Data > Get External Data > From Other Sources area of the ribbon. It's straight out of the Win3x era graphics-wise but it lets you do drag-and-drop style query structures. It does fall apart horrendously once you get to anything approaching complex datasets with many tables, joins, etc. but the precident is there for a graphical IDE baked into Excel.
I used ODBC connections to pull in data for further manipulation in Excel to run a ~$200m project for a couple of years. It saved a great deal of time compared to the manual system that was in place prior whilst presenting the data in the familiar excel system which didn't scare away the old baby boomer who was doing all the manual work beforehand. Once I set up the queries and showed him how to refresh the data from the ribbon, he was able to do it without breaking it and whilst still feeling at home enough to get the job done on his own initative.
edit: I note that the above all falls apart somewhat when you need R/W access to your DB. I've only ever done SELECTs because I want to know info from a DB, crunch numbers, then feed decisions into another system. I don't know if you can UPDATE, INSERT, etc. via Excel/MS Query as I've simply never tried it.
One of my biggest concerns about Excel is it integrates poorly with databases.
A notorious thing that happens in my org is an expert user will extract a bunch of data from the source DB tables and dump the data into an excel spreadsheet. The spreadsheet will pass into the hands of an analyst who will make some tweaks maybe paste in some data maybe manually adjust a few cells here and there and so on and so forth. The spreadsheet will pass into hands of someone else and they will make their own 'adjustments' and so on down the line until finally I will get a phone call along the line of.
"The numbers I have look different to the numbers this other department has in their spreadsheet which is the 'real' value".
Eventually I'll track down the source database and lo-and-behold neither spreadsheet accurately reflects the original database number.
The more hands a spreadsheet passes through the greater the chance of original data being modified into something irreconcilable.
I've played around in the past with linking spreadsheets to DB directly and populating cells via SQL but it fell afoul of requiring various DB/2, oracle, OLEDB etc drivers to be installed on every PC you wanted to open the excel file on and each of those computers required having data source correctly configured via control panel - nightmare for places like my workplace because Windows PC's are all locked down so you'd need to submit a service ticket for every PC you wanted to be able to open spreadsheet on.
This was some years ago but I don't believe anything has changed with way database connection configuration works in Windows client world.
I much prefer the way Dedicated BI tools like COGNOS / SAS etc work. In that situation the user authenticates to the BI software (running on a central server) - the server has all of the DB connections configured and the server executes the DB query on behalf of users.
Our org is currently evaluating a newish Microsoft product called "Power BI" which uses something called an enterprise gateway more info here https://docs.microsoft.com/en-us/power-bi/service-gateway-on... I don't know all the details but seems promising solution for our org's data sharing issues at least.
We're currently trying out QueryStorm [1]. It supports SQL through built in SQLite, but you can connect to any DB and get the full SQL feature set of your DB. It's also possible to manipulate data, and automate stuff using C#. So far it's been quite good. Everyone can view spreadsheets created using QueryStorm, but the data will just be plain data unless they have QueryStorm installed. That's the only drawback.
I really thought PowerPivot could be this excellent data tool, but the DAX formula language is just such a pain. I really dislike it. Using SQL og C# is just much more intuitive - especially SQL.
Currently, running SQL and returning the results to a sheet is possible, but very cumbersome now: either .ODC files, VBA, or PowerPivot, none of which are flexible or developer-friendly.