Database Indexing Mistakes

Many developers are rightly nervous when dealing with databases. Not only is the database absolutely critical to proper functioning of the system, but its inner workings can often be very mysterious to people who aren’t constantly mucking around with it. And worse still, the database and the data within it are often the most valuable part of your application. Making things even more difficult, changes to the database can be difficult or impossible to roll back, especially if data was altered or destroyed by the changes. Small database changes can also have insidious, unpredictable impacts months later, either when the system comes under load or when a large number of records have been added. Such behaviors mean that unless a developer is very comfortable with databases, that they will tend to do things that seem to work well for other people. While this does mean that good ideas and good habits CAN spread around, anyone who has seen how rumors spread in a population probably knows that all kinds of bad ideas WILL spread further. It’s an environment that lends itself to cargo cult thinking. As a result, many developers have misconceptions about databases. These misconceptions sound great in theory, but they aren’t so great in practice. In fact, many of these misconceptions can really cause major database performance issues. There are a lot of common misconceptions about how database indexes work. If you haven’t spent a lot of time studying how databases work at a low level (or thinking about how they MIGHT work from a data structure perspective), it’s very easy to end up with a mental model of things that has no relationship to reality. As a result, many developers have misconceptions about indexes that can seriously harm performance. If nothing else, a lot of these ideas can waste a lot of developer time and cause frustration for team members. And worst of all, these misconceptions often don’t cause problems until the worst possible moment, when the system is under load. However, if you can avoid these misconceptions, you’ll tend to write better SQL code. If you got nothing else from this episode, it’s important to understand one thing – measure your results when making database changes, rather than making assumptions about what those results will be. Links Join Us On Patreon Level Up Financial Planning

Om Podcasten

Will and BJ first met in college and have been friends ever since. You can tell this through their dynamic conversations. Will bring a wide knowledge base to the conversation through his years of experience as a senior developer and aspiring software architect. Whereas BJ being a journeyman developer is learning as he works in the field. He shares those lessons and more each week. Because of their varied experiences topics range from the technical to the every day life of a software developer. Whether you are just starting out or in the twilight of your career you'll find something useful and informative on Complete Developer Podcast. There are plenty of podcasts out there focused on languages and coding. What we are doing with the Complete Developer Podcast is to also cover the other areas of life as a developer.