Welcome to the first in a series of weekly articles I have cleverly called Database Geek of the Week. (I expect that if “geek” rhymed with “month” the interviews would have been monthly.)

Initially I thought it might be too difficult to do an interview each week. But after running out of fingers and toes on which to count the appropriate subjects, I figured that doing this weekly would work out. Some of the folks I interview will be relatively well known, others quite a bit less so. But they all have one thing in common: a love of developing systems using databases.

Geeks being, well, geeks, we are often somewhat isolated from others in the craft. I, for one, most often work in my basement home office, rarely visiting client sites. Even when I worked in an office with other developers, I found that I did not have a great deal in common, technically speaking, with folks involved in areas such as client-side HTML, mini-computer development, and other areas not directly related to my interests. Instead I found little glimpses of the personalities and interests of my fellow geeks in private newsgroups that were not strictly technical. I hope that I capture a little of that in these interviews.

Doug: Ever since Laetitia Thompson asked President Clinton “Boxers or briefs?” interviewers have tried to ask edgy questions (http://blog.rockthevote.com/2005/02/little-history-of-rock-vote-and-boxers.html). This being a geek-related interview, I ask: Stored procedures or ad-hoc SQL? And why?

Terri: I know this question can incite some deep religious fervor, but I am on the stored procedures side of the fence. The SQL scripts I need to write for most of my applications are heavily process-driven, and stored procedures are the best tools for those jobs. Stored procedure code is easier to write, troubleshoot and test because it can all be done from the Query Analyzer environment, which is better suited for those tasks. This also allows for SQL experts to do that part of the job and leave the web site development to the web developers. Having the SQL code isolated in stored procedures also helps tremendously in performance monitoring and tuning. It also helps with source control and versioning.

Doug: When you program in .NET, is VB.NET, or C# or some other language your favored language?

Terri: My employer has decided upon a VB.NET policy, so that is the language in which most of my coding is done. I do admit that VB.NET feels like a comfortable old shoe, but with a new pair of spiffy laces. It does make programming against the .NET Framework more approachable for those used to working in VB. Many will deny it, but there is still a palpable stigma associated with being a VB.NET coder versus a C# coder. Personally, I prefer C# and write some of my side-project code in it.

Doug: There have been a number of blog posts, even petitions, to bring back official Microsoft support for VB6. Any thoughts on the matter?

Terri: There is a huge VB code base and VB has always been Microsoft’s bread and butter, so my knee-jerk reaction upon hearing this was “Oh no, what a mistake!” But thinking about it rationally, it is not like a big VB plug is being pulled on March 31 and all code will cease to function. VB is not Microsoft’s future so I can understand the decision. But I do think more effort needs to be put into helping developers form an education migration path from VB to VB.NET.

Doug: One thing you cannot help but notice in the circles in which we travel is that you are one of relatively few women. How do you feel about that, and can you think of anything we can do to try to even out the genders a bit?

Terri: Well it is nice to never have to wait in line at the restroom. Why aren’t there more women in IT? I have heard this referred to as an unanswerable question. Many greater than I have pondered it and no answers have been forthcoming.

Doug: How did you start out working on databases? What was your first database-related job?

Terri: My first professional job was back in 1989 as a maintenance programmer on an MRP system that ran on the Pick OS. This was my first exposure to relational database design. Luckily the system was already built and had a solid architecture so I had a strong foundation in database layout.

Then I moved to another company that also used the Pick OS, but for managing databases for publishing. Here I moved into a programmer/analyst position where I designed databases to hold relational data for database directory publishing. We had Marc Rettig’s Rules of Normalization poster hanging on the wall, explaining normalization in terms of a puppy kennel. Since I worked in a windowless cubicle, I often gazed at it and used the principles in my work.

Doug: You currently use Microsoft SQL Server. How did you manage to get to that database?

Terri: The company I work for is a Microsoft shop. We had been using Visual FoxPro as well as Microsoft Access for our desktop applications. When we started to develop web applications we initially chose Access as the database back end. However, we quickly discovered Access’ limitations so the logical successor was Microsoft SQL Server. Our small web applications, complete with inline SQL code, ported rather easily to SQL Server and we’ve been chugging right along ever since.

Doug: Without violating any non-disclosure agreements, what sort of work are you doing these days?

Terri: I am working for a marketing support company where my primary responsibility is lead developer for our online order entry and fulfillment system. This system is currently running on an ASP 3.0 front end and a Microsoft SQL Server back end. I do the majority of the analysis, programming and customer support for the application. This involves a lot of back-end transactional SQL Server work as well as reporting.

Doug: Have you had any chance to work with the betas of Microsoft SQL Server 2005? What do you think about possibly using VB.NET or C# for stored procedures?

Terri: I have not had the chance to play with SQL Server 2005, but I have tried to keep up with the buzz about it. Although I am comfortable with T-SQL, it does fall short in some areas, so managed code has the potential to fill in some gaps quite nicely. However, my feeling is that adoption will be slow as the DBAs ultimately responsible for the database will be reluctant to give up control.

Doug: Have you read any good database-related books lately? Any general programming books?

I have been reading Microsoft’s Patterns and Practices series, in particular Designing Data Tier Components and Passing Data Through Tiers (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp). Every developer needs to read the content in this series. It is remarkable to me that these resources are free for the taking.

I am also in the middle of reading Mike Gunderloy’s From Coder to Developer (http://www.codertodeveloper.com). This book is an extremely easy read. I’ve found the content to be somewhat lightweight; it is definitely geared toward the very small shop.

Doug: Can you think of a particularly cool tip or trick that many database developers do not know about?

Terri: My best SQL Server hints are performance related. Performance can often be an area that is overlooked until things come to a grinding halt. We’ve all been there.

Use the NOLOCK optimizer hint on SELECT queries where dirty reads are not a problem! This can drastically improve the performance of queries, especially where there is a lot of contention for the same data.

Cursors are evil, mmkay? Use set-based operations whenever possible. But if you have exhausted the set-based possibilities and are stuck having to perform procedural code, use a temporary table instead of a cursor! This will reduce the overhead needed for your process and will therefore perform better.

Do you know someone who deserves to be a Database Geek of the Week? Or perhaps that someone is you? Send me an email at editor@simple-talk.com and include “Database Geek of the Week suggestion” in the subject line.