It's a great time to be a DBA, of any flavor. I am a SQL Server DBA in the Seattle area, and I love what I do. The SQL Server online community is rich and varied, with some of the smartest and most generous IT people you'll find, and the product itself is in a very good place lately. I have relied on that community to build the expertise that makes my career possible, and I hope to "pay it forward" with information provided here. (Every blog seems to have this type of introductory post, and most are dull, because there's not much to say that isn't in everyone else's introductory post, here I am, starting a blog, yadda yadda yadda, so I'll keep this short :-).
You can tell a lot about a DBA's philosophy from his/her position on a few topics that inspire ... erm ... passionate responses in the community. So here are a few things about me:
- Rule One is to know what I don't know. More than a few folks have gotten into embarrassing situations, or worse, just by forgetting the enormous amount that they don't/can't know in this insanely complex field. I am one of those very people, so I try to be extra vigilant and open to being wrong or ignorant about things. I'm sure I'll post something incorrect here once in a while, and I hope the community will set me straight.
- I find that if I'm working really, really hard to solve an issue, I am probably not approaching the problem correctly. An extension of Rule One is that most problems have already been examined by someone else. It's almost always better to find the solution than to build it. While there are some exceptions, you really have to be on the very bleeding edge to be working on something no one has solved already. Really! Google (Bing?) first! The IT world is good at many things, but there is a strong tendency toward wheel-reinvention, a tendency that we should resist.
- It seems like an astonishing number of DBA's don't monitor their systems pro-actively. On the one hand there are good, well-known techniques we can use in a roll-your-own scenario, and on the other there are really good off-the-shelf tools available. I am confused about why so many people don't do one or the other, and about the hostility toward just buying a monitoring solution. I hope it's a genuine lack of time and funds, but I wonder.
- T-SQL is a great language, but it applies to a fairly narrow problem (set manipulation using tables). It's amazing what other -- in my view totally inappropriate -- uses it has been forced into. File under "I never saw a screw that couldn't be driven with a hammer. You just need the right hammer!" The fact that it's not very good for those other tasks in no way diminishes it; it's just not designed to do those things. I like CLR integration very much, for that reason.
- I think ORM is (gasp!) a workaround. Probably necessary, and definitely helpful in the near term, but there's a whole lot of difference between relational and object oriented models that ORM just conceals, and in two or five years I imagine it'll look like a bit of a band-aid. It's good to have a workaround at this moment, but I think a deeper solution to that problem would be cool. Maybe work on ORM will lead toward a real convergence of the two models. It's hard to say.
- I think a DBA should be at least conversant about programming outside SQL (especially before yelling at developers). And vice-versa.
- Some types of Stored Procs are good to have, but I find they can be overrated. Stored Procedures for encapsulating data manipulation are great. For protecting against SQL Injection (if implemented correctly) they are useful. A Stored Proc that just returns a result set, on the other hand, is not really that helpful. CRUD procedures, likewise. There are other, better ways to get all the advantages of encapsulation and query plan re-use. (I said I would weigh in on the hot-button issues, remember? This is one where I feel like I know all the detail of all the arguments on both sides, so please bear with me.)
- I have nothing against other platforms. Oracle, Postgres, MySQL, whatever you like. I don't know anything about those other platforms, but, again, Rule One applies. Oracle RAC looks really interesting.
- I like theory. I am glad people like CJ Date are doing things like what he is doing, even if it doesn't all apply to available software right this minute. It's important that something as ubiquitous as relational databases have a long term vision.
Now that I look at, this first post isn't really short at all. Ah, well. In joining this site I hope to provide something useful, or at least thought-provoking, and that where I am wrong someone will set me straight. Thanks for visiting!