3 ms·

"Stop emailing SQL queries or pasting them in chat" Hunh you don't you put your queries in sprocs and store that in the data base and your source control syste

"Stop emailing SQL queries or pasting them in chat" 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

rcdmd 9y ago
> Hunh you don't you put your queries in sprocs and store that in the data base and your source control system of choice. Not everybody enjoys sprocs-- having 3 sources of truth (repository, dev db, prod db) gives me headaches.
- walshemj 9y ago
  so you have the same problem with code dev test and live you just need to be professional about it.
  - rcdmd 9y ago
    Are you really arguing that "you already have 1 deployment headache, why not add more?" One of the signs of professionalism is simplicity-- reducing moving parts and things that can go wrong.
    - walshemj 9y ago
      so is your not your sql code in the same way the non sql code is ? Ignoring source control for you database is highly unprofessional and in my opinion just lazy.
      - rcdmd 9y ago
        Nobody's "ignoring source control." Statements are written as .sql files in git repositories.
the_angry_angel 9y ago
Story time; 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.
- netcraft 9y ago
  I've seen this same story at every job ive ever had or contracted for. Fortune 100's down to mom and pops. 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.

rcdmd 9y ago

> Hunh you don't you put your queries in sprocs and store that in the data base and your source control system of choice. Not everybody enjoys sprocs-- having 3 sources of truth (repository, dev db, prod db) gives me headaches.

walshemj 9y ago
so you have the same problem with code dev test and live you just need to be professional about it.
- rcdmd 9y ago
  Are you really arguing that "you already have 1 deployment headache, why not add more?" One of the signs of professionalism is simplicity-- reducing moving parts and things that can go wrong.
  - walshemj 9y ago
    so is your not your sql code in the same way the non sql code is ? Ignoring source control for you database is highly unprofessional and in my opinion just lazy.
    - rcdmd 9y ago
      Nobody's "ignoring source control." Statements are written as .sql files in git repositories.

the_angry_angel 9y ago

Story time; 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.

netcraft 9y ago
I've seen this same story at every job ive ever had or contracted for. Fortune 100's down to mom and pops. 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.