When I first started to learn the art of technology evangelism working for NeXT in the 1990s, object-orientation was a relatively new topic and their was a lot to learn about the benefits of software techniques like encapsulation, inheritance, messaging and dynamic binding. But many of those systems were created before we had the world wide web and many of the key messages that were appropriate then have become less important today as we live in a highly distributed web environment. I would like to suggest that we consider re-focusing on a new aspect of web application development: resource orientation.
Resource orientation asks the web application developer to think about creating consistent and precise URLs (URIs) for things that you want to manage. If you manage customers, invoices, purchase orders or products, think about how you identify these items and the data they contain. After you do this you will find that you have some new friends to help your web application fly. Let me introduce you to them.
Your first friend is the resource your local computer's local memory or RAM. Local memory is very fast and you can usually transform resources in memory to the screen in fractions of a millisecond. You don't have to ask the slowly spinning hard drive to go look for a resource - it may be just sitting right there for you. When you use XForms you have the ability to load resources directly into a "model" in your browser. Every selection list can be waiting in memory to pop up on the screen and even web applications with many large selection lists can load instantly in your web browser.
Your second friend is your local hard drive or what is known as your web browser cache. Although the local cache is much, much slower then your local hard drive (by about three orders of magnitude) it still is a great resource to put your data items into. Many people often think that the web browser cache is only for static HTML pages and images. But it also works just fine for storing XML data that is reused between screens or web applications.
Your third friend is your regional web cache, or corporate cache. These are sometimes called a Squid cache after the name of a popular open-source software package that manages and optimizes caches. If you manage IT within your organization you may know that a corporate proxy cache dramatically reduces your Internet bandwidth needs and improves response times for your users by caching and reusing frequently-requested web resource including static pages, images and XML resources. Although initially Squid farms were small and flat we are now seeing much more complex Squid cache hierarchies that attempt to optimize the need to retransmit data around the Internet. Squid can also be used by content providers deliver content from around the world - copying only the content being used, rather than inefficiently bulk copying all content to regional locations.
An extension of the corporate proxy is a regional data cache provided by commercial companies like Akamai. Although frequently set up for large time-critical file transfers such as sound or video files that need real-time playback, these systems are now an integral component of our internet infrastructure and many regional ISPs are providing services using these systems to minimize their need to constantly re-transfer data to and from the Internet backbone.
A fourth friend is the web cache in your own web application server cluster. Web application servers frequently are not a single web server but cluster of multiple web servers that have a load-balancing device in front of it. These load balancers direct each incoming web request to the least-busy web server to ensure that all requests for web resources are handled efficiently. They usually are smart enough to know when a web resource is static and it has a local copy or if they need to bother the database server for new data. They frequently use timestamps on files to know if data needs to be refreshed from another server.
And lastly, consider that databases servers themselves also may have a cache of information that they hold before they decide to do additional work. Many new databases have an innovative column store structure that pre-calculate sums and averages for you. If your resource needs an updated total on an order that total may already have been pre-calculated by the database for you.
What I find is that some of the newer web application architects don't have a precise mental model of these five friends and how they each can help your application perform. Many web application engineers don't appreciate the fact that if you are sending SOAP messages from your server to a client application you are not going to give your five friends a lot of hints to help you. But if you design your URIs correctly your five friends will be standing by to help.
This is one reason why the XRX web application architectures are becoming so popular. They try to leverage the infrastructure of the web and they don't try to short-circuit a system that is already in place to help you.
Before you bother your database server to do a huge number of SELECTs with joins on dozens of tables, considering asking your five friends for some help. You might just find your web application runs a little faster. And remember that native XML databases like MarkLogic are usually inherently faster then RDBMS systems since they may already store the information in the appropriate hierarchical structures.