Today we have a guest editorial. Steve was supposed to be on vacation out of town, but is mourning his inability to do so.
In some bigger companies, there can be more than one DBA or database professional. In the previous company I worked for, I was the only database professional, so anything database related came to me. Of course, this also helped hone my database skills, since I had to find solutions to things I was unfamiliar with. In some ways it was nice to be the go-to guy. It gave me a feeling of purpose, knowing I played an important role that no one else could play. Unfortunately, I also had to deal with some things I wished could be someone else’s problem.
The company I work for now is a much larger organization with many more database professionals. There are a number of different groups and systems. Several of the systems integrate with each other. On some occasions we have queries that span multiple databases. This is especially true for some of our reporting systems. A few of these databases I am very familiar with, since I work with them every day. I understand the tables and the structures and know where the data resides. I am not as familiar with some of the other databases. They still have tables and are normalized, but I just haven’t spent as much time with those systems.
Know how sometimes you start to get to be known for certain things in your job? Or perhaps you helped a coworker with their query problem, so they start to come to you first no matter which system they are working with. This happened to me recently. I have become the go-to guy for database problems or questions in the group I am in. My coworkers usually come to me first when they have a query problem or performance issue or just a question about anything related to the databases. Anyway, a query with a performance issue came my way. The query that wasn’t performing spanned two databases. The main database in the query was one of the ones I am not as familiar with, but it was joining to a database that I know very well.
As I looked more closely at the performance issue I realized I could probably figure out a solution to this problem, but it would take a while since I wasn’t an expert with the main database in the query. Actually I realized this problem was one that would be better served by sending it over to the DBA that managed the database that I am less familiar with. It was a little hard on my ego to let the problem pass, but in the end it was the correct decision. The other DBA was able, in a short period of time, to rearrange the query to properly use existing indexes. He was able to fix the performance problem in a very timely manner. Looking at his solution I was impressed and learned a little more about how things work in that database.
This experience helped me realized that I am not always the best person for the job. It benefited everyone involved for me to not try and solve this problem, since the problem was fixed quickly and I was able to learn something, too. It was a good lesson for me to realize I don’t always have to be the go-to guy and sometimes somebody else is the best person for the job. Share a time you realized you weren’t the right person for the job and how that worked out.