Comment by trueno

and i think this is somewhere in the ballpark of a p good approach, treat it as a dataset that has some predefined queries to get what's needed if you're OCD about seeing it in the code

sql is an interface query way to talk to databases, and treating things as datasets where their initialization query lives in a certain spot that flows into something generic/typed or whatever so that it can be wrangled elsewhere in the code with its own bespoke guarantees and handling behaviors is fine i think

i think i just don't think seeing sql in code or near code is a bad thing at all, to me it just means this code talks to a database and its using the database dialect/language to query the data. maybe people see string replacements over the query to apply variables or whatever as a bad thing i dunno, I think it's a relatively simple way to look directly at how a query might be dynamically adjusted on the fly. i dont have to like step through the lineage of methods and whatever other abstractions to formulate _how_ it put a query together. it's definitely annoying that there's some wild west feel to having so many dialects of sql, but it's a hard bet to make that you're going to make a better sql in 11 lines of code. SQL looks different than code because it is different, it's entire function is different, different paradigms are at play it's specifically purposed for querying and it excels at that on every front.