October 3, 2022 at 12:00 am
Comments posted to this topic are about the item The Growth of IQP
October 3, 2022 at 10:54 am
This was removed by the editor as SPAM
October 4, 2022 at 12:58 pm
IQP is important because there are more processes reading the database, not all of them written by developers. Some are generated by reporting tools or ORMs. This sort of code is pretty generic and doesn't take advantage of SQL Server in particular.
October 4, 2022 at 1:47 pm
IQP is important because there are more processes reading the database, not all of them written by developers. Some are generated by reporting tools or ORMs. This sort of code is pretty generic and doesn't take advantage of SQL Server in particular.
It's a slippery slope of a situation imo. Making those tools into efficient query writers in passive reaction to their ever expanding anti-patterns seems potentially unwise imo. It's like volunteering to stand on a banana peel while holding handrails. Yes you've got the handrails to help you. There might be a better way tho lol. How about not standing on a banana peel to begin with? From a practical point of view many people (note: here's my bias confession) made the decision to not wait around for MS to get IQP working great. In practice instead of "catch all" queries or procs it could be two or three or as many as it takes. However many queries or procs as it takes to get good plans. So what does the future of these developments hold for us non-waiters? We'll get to lower our standards and rely on "catch all" and load up on the parameters and sort it all out in the queries? Maybe a single grand UNION ALL procedure? That's the extremity but is it the ideal?
Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können
October 4, 2022 at 3:27 pm
I don't think IQP is the end-all, and in many cases, poorly written procedures that are "catch-all" still can perform really poorly. The IQP stuff tries to reduce the edge cases, but understanding it also means that many of you will write much better performing code that takes advantage of these changes for complex queries.
Certainly, one of the main appeals of SQL Server has been that it just works. In fact, in many cases, companies use it without any tuning and it supports their workloads.
October 4, 2022 at 4:38 pm
Steve Collins, I don't see how we can avoid using ORMs and report writers. They boost productivity. IQP may also make it easier for "real" developers to get away with sloppy coding, and yeah, it offends my sensibilities a little bit. But...
I remember a discussion about query tuning where we talked about the cost of refactoring some bad code versus the cost of boosting memory. It turned out that increasing the memory was cheaper, solved the problem, and also helped workloads that we weren't looking at. So overall, an argument against being a super efficient developer all the time. Sometimes the easy fix is good enough.
October 4, 2022 at 10:16 pm
ORM only makes sense if the mapping is necessary, no? Otherwise, if it's easier to not use ORM then it becomes a waste to use it. Imo since .NET 6 it's hard to imagine good reasons for using ORM. At least for what I do. It depends on familiarity and what works for people I suppose
Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können
October 5, 2022 at 1:04 pm
In my office, the team that uses ORMs is not the same team that does database work. (And they use Java btw.) Similarly the database team is not the reporting team. I can't impose on either of them, and I also probably couldn't come up with a good ROI even if I could.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply