Use your metabase/tableau/redash to provide them with that data and let them get it out in excel and do whatever they want. 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.īut if its a matter of excel being where your users want to look at and work with the data - I say embrace that. Right tool for the right job.Ī decade ago I would have had a lot of ideas for you but as time goes on the more I have learned to embrace excel. However living in the real world, I personally feel it needs to be balanced in conjunction with tools like PopSQL, metabase, etc. If the report creation/alteration requests don't come often, then I'd argue it's ideal. There are undeniably good reasons for storing reports, alerts and data warehouses (developer maintained objects) in version control. If the tool is more appropriate it could off load some of the things that SQL is not good at would be much easier to find to reduce the cruftĤ. reduction of reports being duplicatedģ. Discoverability through prettier annotations, etc.
#Colaberative sqleditor full
Ad-hoc queries that didn't really need to be full objectsĢ. However, a tool like PopSQL, metabase, etc. With more restraint this wouldn't have happened. I totaly understand that this was entirely a human problem. 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. 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).ĭemands 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". Almost all of the original authors have left and documentation has been lost or just didn't exist in the first place. Very often the old objects were left behind "just incase". Naturally some of these have been superseded.
Since about 2012 they've had various employees generating reports, alerts and data warehouses as objects in the database. Other areas of the business cannot be without these reports under any circumstances. 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). PL/PgSQL's EXECUTE is not to be confused with the EXECUTE that is used with stored procedures.īonus points if you edit the query by shelling out to sed or butterflies. SELECT queries.query FROM queries WHERE name="update-rank" AND version="borked-1"ĭO $$ EXECUTE query INTO result $$ - Something like that, I'm guessing.
#Colaberative sqleditor update
borked-1" received from server process with PID 8448.Īsynchronous notification "chat" with payload "Bob: I have it set to update in a temp table, so we don't have to reset the real table" received from server process with PID 8448. NOTIFY chat 'Alice: Bob, please insert that query into the new queries table, and then NOTIFY "chat" with the name and version of it' Īsynchronous notification "chat" with payload "Bob: See update-rank, v. Or, we could just go all meta, in a Postgres shell:
0 kommentar(er)
