4 ms·

> I am curious as to what a larger codebase with "just SQL queries all over" ends up looking like. I have to imagine they all end up with some (granted, special

by lijok 3y ago

> I am curious as to what a larger codebase with "just SQL queries all over" ends up looking like. I have to imagine they all end up with some (granted, specialized) query builder pattern. But I think my bias is influenced by always working on software where there are just so many columns per table that it would be way too much busywork to not use something. You end up writing a query per usecase, rather than writing generic queries that can be stitched together however in the business logic

rtpg 3y ago
So what happens is that you have the one query that runs for a specific page and fetches the data and the relevant fields? I could definitely see that working for many projects, at least while your objects don't have too many tiny little details to pull out of thhe DB
llanowarelves 3y ago
I think it ends up being hybrid, like seen in CQRS and especially with DDD. Toss in "Vertical Slice Architecture" as well. What abstractions you want can decided on a per command or query basis and it feels natural.
deleted 3y ago
[deleted]
evantbyrne 3y ago
The first agency I worked at did this on their Java projects. They should have just used a fully baked ORM. Basically, they ended up creating a massive query layer in the program which contained all the different queries organized into different interfaces. To edit a simple API endpoint you would have to open like 5 different files at a minimum. And because queries were usually tailored to logic in a specific controller, they were not typically reusable. It was always a relief to go back to Django after dealing with that.
baq 3y ago
Have this right now. Fortunately no custom query builder. It's enough of a hell as is. Cleanup will take years.
- lijok 3y ago
  What problems are you finding with it?
  - baq 3y ago
    Injection potential through the roof, copypasta galore, refactoring the same join pattern in a hundred different queries gets old rather fast… the usual suspects.
    - lijok 3y ago
      Oh god, good luck
pjmlp 3y ago
That is what stored procedures are for.

by lijok 3y ago

rtpg 3y ago

So what happens is that you have the one query that runs for a specific page and fetches the data and the relevant fields? I could definitely see that working for many projects, at least while your objects don't have too many tiny little details to pull out of thhe DB

llanowarelves 3y ago

I think it ends up being hybrid, like seen in CQRS and especially with DDD. Toss in "Vertical Slice Architecture" as well. What abstractions you want can decided on a per command or query basis and it feels natural.

deleted 3y ago

[deleted]

evantbyrne 3y ago

The first agency I worked at did this on their Java projects. They should have just used a fully baked ORM. Basically, they ended up creating a massive query layer in the program which contained all the different queries organized into different interfaces. To edit a simple API endpoint you would have to open like 5 different files at a minimum. And because queries were usually tailored to logic in a specific controller, they were not typically reusable. It was always a relief to go back to Django after dealing with that.

baq 3y ago

Have this right now. Fortunately no custom query builder. It's enough of a hell as is. Cleanup will take years.

lijok 3y ago
What problems are you finding with it?
- baq 3y ago
  Injection potential through the roof, copypasta galore, refactoring the same join pattern in a hundred different queries gets old rather fast… the usual suspects.
  - lijok 3y ago
    Oh god, good luck

pjmlp 3y ago

That is what stored procedures are for.