Hunh you don't you put your queries in sprocs and store that in the data base and your source control system of choice.
Soory I don't see what problem this product is for apart from maybe enabling sub optimal coding practices
I've recently started working with a SME (<100 users) who took this approach after abandoning the vendor's reporting recommendations for their Line of Business application (apparently it was just crap).
Other areas of the business cannot be without these reports under any circumstances. Negotiation is not an option.
Since about 2012 they've had various employees generating reports, alerts and data warehouses as objects in the database. Naturally some of these have been superseded. Very often the old objects were left behind "just incase". Almost all of the original authors have left and documentation has been lost or just didn't exist in the first place.
Many of these objects are dense and difficult (because SQL was the wrong tool for the job, or because they go many layers deep like matryoshka dolls).
Demands for changes to reports are frequent (weekly), and some reports functionally overlap, but produce wildly different results for different areas of the business based on various "rules".
Honestly, the database is a fucking mess (approximately 1900 objects relating to reports, alerts and data warehouses - some of which are dolls going many many levels deep., There's a huge sense of shame and fear over trying to regain control.
I totaly understand that this was entirely a human problem. With more restraint this wouldn't have happened. Both inside and out side of the IT team. However, a tool like PopSQL, metabase, etc. I believe would've helped with;
1. Ad-hoc queries that didn't really need to be full objects
2. Discoverability through prettier annotations, etc. - reduction of reports being duplicated
3. Auditing - last access/run times, etc. would be much easier to find to reduce the cruft
4. If the tool is more appropriate it could off load some of the things that SQL is not good at
There are undeniably good reasons for storing reports, alerts and data warehouses (developer maintained objects) in version control. If the report creation/alteration requests don't come often, then I'd argue it's ideal.
However living in the real world, I personally feel it needs to be balanced in conjunction with tools like PopSQL, metabase, etc. Right tool for the right job.
I think metabase/redash/etc is a great fit for the development of reports and the kinds of things that dont need to be anything more than a sql query. IME fast turnaround can be huge for lots of businesses.
I agree with all of your points. A lot of the problem is organizational and political and historical - but the right tool can make a big difference.
That seems to be one of the biggest hurdles I think I'm going to have to figure out, rather than the technical side.
Theres two directions you could be coming from though - if its a problem of the users producing data and storing it in excel instead of your database thats more of an application problem.
But if its a matter of excel being where your users want to look at and work with the data - I say embrace that. Use your metabase/tableau/redash to provide them with that data and let them get it out in excel and do whatever they want. Give them a little time and then let them show you what theyre doing with it.
IME about half the time theyre actually doing things with it that you cant really help them with unless you spent a ton of time. The other half you can take what theyre doing and either apply those changes into the query itself, saving them time and sharing that work with others - or teach them a better/easier/faster way of achieving whatever it is theyre after. I use it as a long-tail way of gathering requirements a lot of times - let me give you all the data you might need for this and you figure out how it can be useful for you.
Not everybody enjoys sprocs-- having 3 sources of truth (repository, dev db, prod db) gives me headaches.