3 ms·

> Pull Request-like Review/Approval flow for database queries Terrible description IMO. a query should not need approval. Should use mutation or edit or update

by 38 2y ago

> Pull Request-like Review/Approval flow for database queries Terrible description IMO. a query should not need approval. Should use mutation or edit or update or modification. Even if query is technically correct it just sounds wrong and confusing.

loa_in_ 2y ago
You say it's confusing, but it's exactly what I expected it to be based on the description
jascha_eng 2y ago
I'm not quite sure what you mean. Maybe statement instead of query would be more accurate but I think people get the gist of it just fine. Also, I disagree a manual query like: "select * from credit_cards;" should probably go through an approval flow if you have a table like that in your prod env.
- jamesfinlayson 2y ago
  A guy I used to work with said he worked for a company where all queries had to get approved by one of two full time DBAs - apparently with good reason as someone tried to modify a query that would have joined with half the rows in some gigantic table.
  - throwaway84751 2y ago
    I worked at a place where only certain teams with a dedicated DBA were trusted to write direct queries (based on past incidents). All other teams had to ask a central DBA team to build stored procedures for any interaction with the database. If you think that this would create a huge backlog, you are correct... Non critical updates also needed to be coordinated with a "release train" where the code had to be ready 2 weeks before deployment due to the amount of testing it required. It was one of the major drivers behind an initiative to create micro services with separate databases that each team could do what they wanted with. We ended up with a huge number of micro services and special orchestrator services to handle distributed transactions. But I guess that in a company of that scale, there are no perfect solution. At least we were able to make changes within minutes/hours instead of weeks. Paradoxically we also got more pressure to deliver. In the past it was acceptable to leave a healthy buffer at the end of the scrum, to avoid missing the release train. This meant that we often spent the remaining buffer on refactoring, fixing small bugs that we felt we had time for or experimenting with POCs.
    - jamesfinlayson 2y ago
      Yeah I guess I was too inexperienced at the time to ask how well it worked... but I guess like your experience, there would have been a fair backlog.
pjc50 2y ago
No, that's just what everyone calls SQL statements. It's fine. I like this idea. It sits between "developers have access to prod" (no! bad idea!) and requiring everything to be signed in triplicate. It provides a low-friction way to make reviewable changes to prod.
- 38 2y ago
  Big difference between getting rows and changing rows

by 38 2y ago

loa_in_ 2y ago

You say it's confusing, but it's exactly what I expected it to be based on the description

jascha_eng 2y ago

I'm not quite sure what you mean. Maybe statement instead of query would be more accurate but I think people get the gist of it just fine. Also, I disagree a manual query like: "select * from credit_cards;" should probably go through an approval flow if you have a table like that in your prod env.

jamesfinlayson 2y ago
A guy I used to work with said he worked for a company where all queries had to get approved by one of two full time DBAs - apparently with good reason as someone tried to modify a query that would have joined with half the rows in some gigantic table.
- throwaway84751 2y ago
  I worked at a place where only certain teams with a dedicated DBA were trusted to write direct queries (based on past incidents). All other teams had to ask a central DBA team to build stored procedures for any interaction with the database. If you think that this would create a huge backlog, you are correct... Non critical updates also needed to be coordinated with a "release train" where the code had to be ready 2 weeks before deployment due to the amount of testing it required. It was one of the major drivers behind an initiative to create micro services with separate databases that each team could do what they wanted with. We ended up with a huge number of micro services and special orchestrator services to handle distributed transactions. But I guess that in a company of that scale, there are no perfect solution. At least we were able to make changes within minutes/hours instead of weeks. Paradoxically we also got more pressure to deliver. In the past it was acceptable to leave a healthy buffer at the end of the scrum, to avoid missing the release train. This meant that we often spent the remaining buffer on refactoring, fixing small bugs that we felt we had time for or experimenting with POCs.
  - jamesfinlayson 2y ago
    Yeah I guess I was too inexperienced at the time to ask how well it worked... but I guess like your experience, there would have been a fair backlog.

pjc50 2y ago

No, that's just what everyone calls SQL statements. It's fine. I like this idea. It sits between "developers have access to prod" (no! bad idea!) and requiring everything to be signed in triplicate. It provides a low-friction way to make reviewable changes to prod.

38 2y ago
Big difference between getting rows and changing rows