An interview with Bob Beauchemin

by Douglas Reilly

Bob Beauchemin is a developer who not only writes code and develops databases, but also teaches other developers to create applications and databases, often using the latest Microsoft technologies.

Bob has more than 25 years of experience working with IBM mainframes and Unix boxes, as well as Windows-based PCs. He has taught a number of database courses for DevelopMentor, a hands-on training company for experienced developers, and has given instruction on writing .NET web services and creating applications and components using C#.

Bob has written a number of books, most recently A First Look at SQL Server 2005 for Developers.

The following questions were asked by me and answered by Bob via email.

 

Doug: One of the biggest issues among SQL Server developers is whether or not to use stored procedures. Where do you come down on this issue?

 

Bob: I’m guessing that you are referring to using stored procedures as opposed to dynamic SQL in middle-tier or application programs. I’m a proponent of stored procedures; the decision is how much application logic should be put in them.

Too much application logic in stored procedures makes your database server double as an application server, which makes it more complex to manage. On the other hand, processing the data in the same process in which it lives, meaning in the database, makes for less network traffic pushing data back and forth between tiers. So it’s dependent on the speed of your network versus room in your database.

The best reason I’ve heard for not using stored procedures is that the procedural extension languages are all different, so if your product has to run on many different databases, you’re maintaining multiple, distinct code bases.

I would like to make a distinction between procedural extensions to SQL, such as PL/SQL and Transact-SQL, and SQL itself. Whether you use procedural extensions to SQL or dynamic SQL you should always use set-based SQL. Procedural code in server cursors or in the client is not a substitute for the SQL language.

 

Doug: When you program in .NET, I imagine C# is your language of choice, given the courses you have taught. Why is C# your favored .NET language?

 

Bob: I’ve worked with a lot of different programming languages, including COBOL and assembler. In the COM era I used both C++ and VB, among other languages. Going into .NET, it seemed like it was a cleaner transition to C# than to attempt VB6 to VB.NET or C++ to managed C++. The syntax between the “updated” languages was just different enough to be confusing. So, although I can use either C# or VB.NET, C# became my language of choice.

 

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

 

Bob: I haven’t thought about it much; I’ve been using .NET exclusively for a number of years. Visual Basic and VBA certainly have their share of loyal aficionados.

 

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

 

Bob: My first database-related job was working as a programmer on an IBM mainframe system using IMS-DB. Before that, all of the commercial data processing applications I did used indexed files, ISAM and VSAM. At the job where I met up with databases, using them was required and just part of the job.

 

Doug: How did you learn about databases?

 

Bob: I learned about them by working with them, supplemented by the usual learning through courses and books.

 

Doug: Where in the development world do you think XML best fits? What have you used it for, in addition to web services?

 

Bob: XML is used for everything today, from a replacement for comma-delimited files and hierarchical .ini and .rc files, to documents, to a marshaling format, to a data storage and query format, and more. You can even write (XSLT) programs using an XML syntax to process XML. It does all of those things well, but may not be the optimal format for some of its usages. It requires encoding and decoding, and the textual format is verbose.

I’m not sure that rewriting the world in XML will always be the best thing to do, but I’ve been learning XML-based technologies and teaching them to others for quite a while. We’ll have to wait and see. In my book preface, I tell a story about not being particularly impressed with the relational model, as opposed to IMS, at the beginning either.

 

Doug: Your most recent book, A First Look at SQL Server 2005 for Developers, was based on an early version of SQL Server 2005. I have written books about beta software, and it is a very difficult process. How did you find it?

 

Bob: It’s time-consuming because things are constantly being revised, breaking your code samples. And we wrote a lot of code samples, many of them using .NET Reflector or the like for documentation. We actually rewrote the book at least four times before publication. And we’re writing a revision to it for SQL Server 2005 RTM. My first book, Essential ADO.NET, was similar; I handed it in the day .NET 1.0 shipped.

 

Doug: You mentioned on your blog that you will be doing a new edition of your SQL Server 2005 book. What are the most significant differences between the earlier betas and what we expect to be the RTM version?

 

Bob: The most significant difference is in the managed provider area. That changed radically recently with the combining of SqlClient and SqlServer data providers. The XML data type and XQuery support have been much improved over early betas too, and more features have been added. The same is true in the service broker and security areas.

 

Doug: Have you read any good database-related or software development books lately?

 

Bob: I’ve been too busy writing to do much book reading lately, although I’ve gotten to review other writers’ material in the SQL Server 2005 area. The two database books I’ve read recently are XQuery from the Experts and XQuery: The XML Query Language by Michael Brundage. Both are excellent.

 

Doug: What do you think about possibly using VB.NET or C# for stored procedures, user-defined functions and triggers? What sort of guidance can you give to people looking to leverage the procedural code in SQL Server 2005?

 

Bob: I talked about this at the most recent TechEd event. It’s a pretty good start to use T-SQL for heavy data access and CLR for heavy computations. Where you need to test and measure performance is when you have a mixture of both. And neither T-SQL nor SQLCLR is a substitute for a well-written SQL statement to access relational data. Both SQLCLR and T-SQL are procedure extensions.

 

Doug: As you teach and write more, it becomes more difficult to keep a hand in development. What percentage of your time is spent writing code for clients and what percentage is teaching and writing?

 

Bob: Teaching and writing take up most of my time, although I do some consulting jobs as well as advising colleagues and students about their real-world projects. When I started my current job I thought I might have trouble finding consulting gigs, but it’s been more of a problem finding the time for the consulting work.

 

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

 

Bob: My favorite cool trick this month is saving the graphic showplan in SQL Server 2005. It was not possible before now to send the graphic version to a colleague or to tech support. If you turn on the XML showplan and save it with the suffix .SQLPlan, you can send the file by mail and open it in SQL Server Management Studio and re-display the graphic format, complete with hover-over plan details. It’s very cool.

 

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.