Maybe you're like me: you're a developer who has been working with relational databases most of your career, but you treat developing against the database the same way you would if you were slinging some code.
For small datasets, it's probably not a big deal. However, as my datasets have grown, I've learned that I need to change my thinking about the best approach to using a relational database. Example: MAYBE it's a poor idea to `foreach` over the 4 million rows in a table. It worked just fine when there were 4,000 rows.
My lessons were learned the hard way: doing something dumb, seeing it fail horribly in production, and then working backward for a better approach. In the end, we've been able to slice minutes (and sometimes hours) off of database interactions. We've lowered our compute, which has allowed us to use fewer resources.
Let's talk about a couple of the dumb mistakes I've made as a developer using relational databases, the impact it caused, and what the "better" way to approach the problem should've been. Feel free to come to share the lessons you learned, too!
Kevin Griffin is an author, teacher, mentor, and consultant focusing in software development. He is also a 15-time Microsoft MVP, specializing in ASP.NET and web development. As the owner of Swift Kick, a software training and services company, Kevin specializes in helping businesses push their technology stacks into the 21st century. You can often find Kevin speaking at conferences and user groups nationwide or blogging at https://consultwithgriff.com.
This is a recording of a presentation to the Cleveland C# User Group on August 27, 2024: https://www.meetup.com/cleveland-cs/e...