Because a client/server architecture specifically separates out components for UI and data processing, actual application processing is left up to the programmer to integrate. In other words, a client/server architecture does not provide an obvious place for a banking application to do interest calculations. Some client/server applications place this kind of processing in the database in the form of stored procedures; others put it in the client with the UI controls. There is no general solution.

Under MySQL, the current method is to put the processing in the client because of the lack of stored procedure support in MySQL. Stored procedures are on the MySQL to-do list, and—perhaps even by the time you read this book—stored procedures will eventually be a viable place for application logic in a client/server configuration. Whether or not MySQL has stored procedures, however, MySQL is rarely used in a client/server environment. It is instead much more likely to be used with the web architecture we will describe later in this chapter.

There used to be two kinds of clients: fat clients and thin clients. A fat client included application processing; a thin client simply had user interface (UI) logic. With the advent of web applications, we now have the term ultra-thin to add to the list. An ultra-thin client has only display logic. Controller logic (what happens when you press “Submit”) happens elsewhere. In short, an ultra-thin client might be a web form.

The advantage of an ultra-thin client is it makes real the concept of a ubiquitous client. As long as you can describe the application layout to a client using some sort of markup language, the client can paint the UI for a user without the programmer needing to know the details of the underlying platform. When the UI needs to respond to a user action, it sends information about the action to another component in the architecture to respond to the action. Client/server architecture, of course, has no such component.