Hi there! Welcome to my blog!
I guess the best way to start is to introduce myself. Hi, I’m Deb, the DBA!
Who am I?
When I went to college, I decided I want nothing to do with math or science. I majored in English and History. My first job out of school was as a sales assistant. But my co-workers quickly noticed that I was comfortable around the computers. They sent me to classes and I got a promotion to the network admin. Even then, I still spent a lot of time with the sales database. Our contact management program had complicated searches that actually used the words INNER JOIN and LEFT JOIN and I was possibly the only person in the office who could figure out how to put them together. This is how I learned table joins.
As I was getting ready to move on from that job, I had a realization that I often found myself working with databases of some way, shape or form over the years and I liked it. So I would sneak back to the server room with some “Learn SQL Server 7 in 24 hours” type book so I could see first hand what I was seeing in the book. I decided that I wanted to learn databases from the back end rather than just the front facing user interface.
So I left that job for a new one as a junior DBA. I had the little of what I had learned from the book about SQL Server 7 but now, I had to use SQL Server 6.5. Did you know that there are a lot of major differences between SQL Server 6.5 and SQL Server 7? I didn’t. Well, at least not then. I also learned very quickly that I did not know what they were expecting or needed me to know.
Looking back, I feel lucky that I even got hired in the first place. But I was also determined to figure out what I needed to do and learn it quickly. Oh, and I did not want to get fired because I wasn’t able to catch up and embarrass myself along the way.
I spent a lot of time on that job learning how to be a DBA and about how SQL Server worked. I spent a lot of my free time reading various SQL Server websites so I could understand what I was expected to know. I learned database maintenance, but I spent most of my time working with programmers helping them design tables and write more complicated SQL queries and procedures. I even worked with new hires and introduce them to the basics of SQL. And after several years there, I’ve been able to take all of that experience and move over to my current job where in some sense, I do much of the same but applying it in different ways and being able to use all the new tools that didn’t quite exist at the time.
Why blog now?
I must confess – I haven’t been too involved in the general SQL Server Community over the years. I did manage to make a PASS Summit once about 12 years ago. I try to make the local SQL Server user group meetings when I can but it’s not very regularly. I do make the local SQL Saturdays and I finally volunteered at the last one I attended. I follow various people in the SQL Server community and the SQL Server related handles on Twitter and will occasionally tweet something fluffy myself.
I’ve been toying with the idea of a blog for a while now. My problem has always been: What would I say? I have enough problems figuring out a basic tweet! But I’m starting to believe the hype going around that we all have something to add to the community at large. I know I have a different way of approaching things so perhaps that can help someone else look at something through a different lens so they can understand it better. And when I have made it to an event and I talk to people about some of the projects I’ve worked on, I think I have had a chance to do some cool things over the years.
But I also believe in explaining what I look for when my programmers send me objects or more complex stored procedures and SQL. I say it’s because I’m lazy – if everything’s in order, less work for me to do. But honestly, I think it helps them understand the the database and how it works and the differences in database design versus just generating database tables from the objects in their code. If they understand the database better, they can build their application better as well. You can write the best code in the world but if it’s using a poorly designed database that doesn’t have data integrity and\or isn’t optimized to handle the data, the code is going to be bogged down by the workarounds for those issues. I see my job as helping prevent these problems. We’re a team and I’m here to help.
I guess there’s nothing left to say but, let’s do this!!