SuburbanFarmer wrote: ↑Mon Aug 26, 2019 1:13 pm
Speaker to Animals wrote: ↑Mon Aug 26, 2019 9:06 am
SuburbanFarmer wrote: ↑Mon Aug 26, 2019 9:03 am
I’ve been surprised at how much trouble C devs have with SQL. There’s a lot to know behind the scenes.
SQL is just a completely different thing that people have to get used to. Databases in general are their own thing with a lot of intricacies and pitfalls that are very unique.
Anybody can learn to write queries and pass that through some kind of API. But beyond that, we really don't want to mess with a database. For the sake of robustness and basic software engineering principles we like to hide all that behind adapters in some API that can handle a lot of error and sanity checks for us.
The guys I work with now like to put all of their recurring queries into the codebase, rather than stored procs in a sql. Makes my job super fun.
You definitely don't want to write the queries into your code. You want to encapsulate that shit so you can contain errors and complexity.
That's why we don't have much exposure to it. It's a very different world and it is poor practice for us to even directly deal with it in our code anyway.
I am a real time systems guy, so my exposure is even less, but right off the top of my head.. If I had to deal with that sort of thing and I was in an object-oriented environment like Java, I'd just make a class that is a specialized query builder. Pass parameters for what I want to look up, hide the sanity checks and error handling inside of that, and just queryBuilder.build () and pass the result into whatever adapter interfaces I have setup to deal with the database. I am just spitballing there. Not sure how those business domain guys handle it routinely. I am just telling you my first thoughts on what patterns I would consider.
I sure as shit would not have actual SQL strings in my code outside of something like that QueryBuilder class.
