So Brent Ozar is a super smart SQL guy that does a great job teaching how SQL works and what you can do with it. He does have paid courses, but he also has some free basics courses that really help you understand how SQL works. I got an email saying that he’s going to be live streaming some of those classes. So if you ever are having issues with performance and want to understand what an index is and how you can at least have and idea of how to write SQL (BAQs) that could perform better. PLEASE go do these classes. I promise you won’t regret it.
Disclaimer: I get nothing from promoting Ozars stuff. (Except, maybe (hopefully) a few less ignorant questions from people trying to figure out why their BAQs take forever!) I just find his classes really good and I’ve learned a LOT from his offerings.
His consulting offerings.. well not so much. We got passed off to someone else, who passed us off to someone else who just basically said “Add more power!”
Ozar’s been a great learning resource for ages. Highly recommended and thanks for the reminder!
The ‘first responder kit’ content will also be useful if you’re a nerd curious. Even for SaaS users or users who otherwise don’t have database access*. Some understanding of performance context and how database design can throw wrenches in the data gears can highlight otherwise unintuitive options that play along better with our particular entrenched database conditions.
* edit to nitpick myself …aren’t offically the DBA or otherwise empowered and expected to do the thing.
Isn’t the performance of BAQ’s far more than just understanding SQL. EPICOR Security business objects are applied on top of this and more often than not performance issues are an EPICOR problem, not a misunderstanding of how SQL works.
Well, yes. You’re not wrong. But you have to start somewhere, and these basics are somewhere to start. If you start at Epicor Security, you’re not going to understand anything.
Not if you are a hack n’ slash programmer just trying to get a grasp on how Epicor works using SQL. Most of the speed issues I come across are of my own making. Like not including COMPANY as a key field…
That’s a good example of how the deep SQL lore helps highlight opportunities. ‘Company’ as an index reference for ad hoc queries should be nonsense on the surface. But, when every index is a compound index, and every compound index has ‘Company’ on its ordinal doorstep, ‘Company’ becomes the gatekeeper for every index. ‘Company’ doesn’t add performance, it locks you out of performance if you don’t acknowledge it.
