There's a large movement afoot in the database industry to replace classic client/server (or two-tier) databases with more complex n-tier databases. What are these systems all about? Are they right for your needs?
You're probably familiar with the classic client/server database. The client is commonly a custom application implemented in a language like Delphi or Visual Basic while the server is a database engine like SQL Server or Oracle. Examine the first image above and you'll see the two-tiered nature of these systems. Commonly, database developers will embed the business logic in the client and/or the server. The fat client/thin server approach advocates embedding as much processing as possible on the client removing the data processing burden from the server and allowing it to serve more clients. Alternatively, the thin client/fat server approach entails developing an extremely light client that consumes few client resources and requires a large amount of server CPU cycles. This approach would be very appropriate when developing applications for wireless applications and other low-power computing devices.
Regardless of the approach you select, I'm a firm advocate of embedding essential business rules in the database engine itself. It never hurts to double-check incoming data and the peace-of-mind is worth the added consumption of server resources. Furthermore, this approach protects the database from future applications that incorrectly or inadequately implement the business rules.
n-tier databases are most commonly implemented as a three-tier model (illustrated in second illustration above). These databases extract the business rules and place them in an independent middle layer. The server and client never communicate directly with one another, passing all data through the middle layer which performs the business rule validation. There are several benefits to this model. First, the middle tier provides a layer of abstraction. Client applications are written to communicate with the middle tier and do not depend upon the type of server that actually stores the data. The back-end server could be changed (say from Oracle to SQL Server) and only the middle layer would require modification. Second, three-tier databases provide a good method to separate responsibilities when database developers are not provided administrative access to the database engine itself for political reasons. Finally, three-tier implementations can be designed to have more efficient network footprints by aggregating operations to reduce bandwidth consumption.
Many people consider database-enabled Internet applications to be three-tiered systems consisting of the browser, web server and database server. While this may be an accurate description from a networking perspective, it's often not true from the database point-of-view. In this case, the web server does not normally implement any of the business rules and, therefore, should not be considered a database tier. It would be more accurate to describe the web server as a component of the database client tier in partnership with the web browser.
Oftentimes, you'll find n-tier databases implemented for all of the wrong reasons. They do make for some amusing anecdotes to share around the virtual water cooler. I recently attended an industry seminar attended by a large number of database professionals. In between sessions, I had an interesting conversation with a Visual Basic developer working for a large agency of the federal government which will remain nameless. He remarked that he recently began the planning stages of a three-tier database system with the assistance of a contractor. When I pressed him for the reasoning behind their decision to implement such a complex system, he admitted that the consultant had sold the idea to senior management as the best thing since sliced bread. Management turned around and directed him to cooperate with the consultant against his protests.
Is an n-tier system right for your needs? Obviously, you'll have to perform a business needs analysis to weigh the pros and cons for your specific situation. I'd encourage you to lean toward a two-tier system and only consider an n-tier system if you can thoroughly convince yourself that the benefits justify the added layers of complexity for design, administration and development.
If you'd like to discuss your specific situation, be sure to join us in the About Databases forum!