The World Wide Web provides a client for client-server applications where the application author can expect the OS vendor to provide a client. It allows the creation of client-server applications that don't require every user to have a copy of the client written for the application. This makes it possible to provide applications to the public at large, instead of just trapped set of customers. The catch is, the clients tends to make requests asynchronously, with no regard to what else is happening on the server, and there can be a lot of clients. This creates headaches for the person writing the application.
Databases are one of the things that the software industry does very well. People have been doing databases for decades, and these are the applications that companies put their mission-critical applications and data in. Being stable, well-understood technology, they make an excellent back end for client-server applications. They deal well with asynchronous requests from lots of clients.
Putting those two things together, it is obvious that database servers are a natural storage mechanism for a web applications data. As soon as a web application begins writing data based on requests from the web, it's time to consider using a database to back the application. Such a system is a 3-tiered application. One tier is the WWW client that talks to the second tier, the Web server, that arranges for requests to the application to run code that talks to the third tier - the database server.
This paper describes building such a system. Because the point is to describe the building, the system is the simplest one would put on the web - a single table that can be updated over the web. I start with accesses that update the table, add a second class of update that should be protected, and finally consider protection and performance issues.