| In this chapter we presented the basics for getting started doing distributed applications with Microsoft SQL Server. Bear in mind that, although we focused here on how to configure and use Microsoft SQL Server 2000, the material in the other chapters in this book are applicable to any database system Oracle, Sybase, Informix, or what ever. So long as there is an ODBC driver or an OLE DB provider that can get to your back-end data, you can use the database from Visual Basic.NET. Questions and Answers | Q1: | I've always been terrified of fooling around with SQL Server. It always seemed like a black art to me. I once knew a guy whose brain exploded after doing a week of constant server-side programming. Will the topics covered in this chapter enable me to create serious database applications with SQL Server without going crazy?! | | A1: | Yes and no. We didn't design this chapter to cover hard-core, day-to-day database administration, performance tweaking, or anything like that. And it's definitely not designed to be a comprehensive guide to SQL Server, just an introduction. The material that covered getting started with SQL Server in the first half of this chapter was designed specifically to let you get comfortable with SQL Server. Migrating up from single-user and small-workgroup computing to client-server isn't trivial, but it shouldn't be a black art, either. That fear is what this chapter is designed to dispel. (As to what is happening to your friend's head, that's between him and his psychiatrist.) | | Q2: | If most of my queries are pretty straightforward and do not contain complicated logic, is there any reason for me to get involved with using stored procedures? | | A2: | Yes. In fact, there are two main advantages to using stored procedures instead of coding your SQL queries in your application code: Performance. For many programmers, this alone is enough of a reason to use stored procedures! The improved performance of a query that is implemented in a stored procedure rather than in the application code is due to the fact that a stored procedure is already precompiled and planned by SQL Server before it is called to be executed. When an SQL query string is passed from the client to the SQL Server to be executed, it must first be parsed and compiled, and have an execution path determined, before it can actually be executed. That is a lot of overhead to be paid at run-time, when you are trying to squeeze out as much performance as possible. Manageability. Implementing queries as stored procedures means that all of an application queries are stored in a single, central location, rather than strewn throughout the thousands and tens of thousands of line of application code. Moreover, it allows multiple projects or applications to utilize the same code if they are using the same database. This means less work (coding/debugging/testing) and less bugs. It also allows us to leverage the advanced security control mechanisms offered by SQL Server. Finally, using stored procedures offers the option of "divide and conquer" or specialization, for the development of the application code. The application developers, who specialize in the business logic and flow of the application can focus on their application code, while leaving the database access and querying to the database gurus working on the server. |
|
