Database Access in the Web World

Accessing a database in a web application is a completely different scenario than accessing a database in a typical client-server desktop application. Most developers hone their database skills in the desktop world and run into serious problems when they try to apply what they have learned with stand-alone applications in the world of the Web. Quite simply, web applications raise two new considerations: problems of scale and problems of state.
Problems of scale are the problems that can result from the massively multiuser nature of the Web. A web application has the potential to be used by hundreds or thousands of simultaneous users. This means it can’t be casual about using server memory or limited resources such as database connections. If you design an application that acquires a database connection and holds it for even a few extra seconds, other users may notice a definite slowdown.  And if you don’t carefully consider database concurrency issues (in other words, what happens when the changes from different users overlap), you can run into significant headaches, such as failed updates and inconsistent data.

Problems of scale can occur when developing traditional client-server desktop applications. The difference is that in most client-server applications they are far less likely to have any negative effect because the typical load (the number of simultaneous users) is dramatically lower. Database practices that might slightly hamper the performance of a client-server application can multiply rapidly and cause significant problems in a web application.

Problems of state are problems that can result from the disconnected nature of the Internet.
As you already know, HTTP is a stateless protocol. When a user requests a page in an
ASP.NET application, the web server processes the code, returns the rendered HTML, and closes the connection immediately. Although users may have the illusion that they are interacting with a continuously running application, they are really just receiving a string of static pages.
Because of the stateless nature of HTTP, web applications need to perform all their work in the space of a single request. The typical approach is to connect to a database, read information, display it, and then close the database connection. This approach runs into difficulties if you want the user to be able to modify the retrieved information. In this scenario, the application requires a certain amount of intelligence in order to be able to identify the original record, build a SQL statement to select it, and update it with the new values.
Fortunately, both ASP.NET and ADO.NET are designed with these challenges in mind. As you work your way through this chapter (and the following two chapters), you’ll learn how to deal with databases safely and efficiently.