 | MySQL & mSQL |  |
The Client/Server Architecture
Data Processing
Object/Relational Modeling
The Three-tier Architecture
Before we explore the details of database application development in various languages, we should take a moment to take a broader look at the question of how you architect database applications. The focus of this chapter is conceptual; we are going to take a look at the client/server architecture behind database programming. The issues are important for programming with MySQL and mSQL, but they are not specific to these database engines. They are instead issues you can apply to programming in any database environment. Without these concepts, however, you may find that your database applications neither meet your current needs nor adapt to meet any changing needs. Our look at database programming covers such complex issues as understanding common two-tier development, object-to-relational mapping, and two-tier's more cutting-edge sibling, three-tier client/server.
At its simplest, the client/server architecture is about dividing up application processing into two or more logically distinct pieces. We have spent the entire book so far discussing the database as if it exists in some sort of vacuum. It serves its purpose only when being used by other applications. The database, at its simplest, makes up one piece of the client/server architecture. The database is the `server'; any application that uses that data is a `client.' In many cases, the client and server reside on separate machines; in most cases, the client application is some sort of user-friendly interface to the database. Figure 8-1 provides a graphical representation of a simple client/server system.
You have probably seen this sort of architecture all over the Internet. In fact, we will be addressing the specific problem of client/server Internet applications throughout this book. The web, for example, is a giant client/server application in which the web browser is the client and the web server is the server. In this scenario, the server is not a relational database server, but instead a specialized file server. The essential quality of a server is that it serves data in some format to a client.
When you build a database application, you first need some way for the client to communicate with the database. Database vendors like to hide the underlying communication from developers in the form of language-specific APIs. When you write a database application, you write them with special libraries that translate your requests into TCP/IP packets that travel across the network to a database server.
The look of these database APIs varies both according to the language you are writing in and, in many cases, according to the database you are using. Because MySQL's APIs were designed to look a lot like mSQL's, however, all the APIs you will encounter in this book only have minor differences.
|  | |
| II. Database Programming |  | 8.2. Data Processing |
Copyright © 2001 O'Reilly & Associates. All rights reserved.
| This HTML Help has been published using the chm2web software. |