If you look hard enough, you can probably find a database server product that does not support access by Web browsers. Most DBMS readers work primarily with relational databases, and I suspect that most of your efforts to access databases using Web browsers (and servers) involves relational databases. Even in pilot projects, many applications that use Web technology involve transactions, or they serve up tabular data stored in an RDBMS. That's great, but it's not the whole story.
The tidal wave of attention paid to integrating Web browsers and servers with RDBMSs should not obscure the progress made by other kinds of database servers. This Internet Systems supplement offers three features that delve into the nuances of Web browser access to three specialized types of database servers: OLAP or multidimensional databases, text and document databases, and object databases. If you are involved in data warehousing, you may already be working with an OLAP or multidimensional database. More companies are using text and object databases, but they are still not part of every corporate landscape. Relational databases are great for many kinds of Internet and Intranet applications --but not for everything. If you have not carefully considered other types of database servers before, perhaps your next (or first) Web application is a good opportunity to expand your horizons.
At a very high level, most Web-database architectures often look fundamentally the same: A browser sends a request to a Web server, the Web server invokes a program that accesses a database, and the results (if any) are formatted as HTML and returned to the client's browser. The middle space between the Web server and database server has been the crux of the Web-database integration puzzle. Programmable Web servers are also becoming increasingly tuned to application tasks in addition to page serving. (See "Server-Side Development Decisions" by Kevin Reichard on page 6.) Early Web-database integration products consisted of CGI programs, but this approach is fast being eclipsed by more complex software programs that live between the Web and database servers. The advantage of this strategy is that the database server itself need not be modified. The disadvantage is that you must integrate (and manage) yet another piece of software into what is probably already a complex and even brittle environment.
The initial efforts to integrate OLAP data sources disturbed me because the first few products actually took a step backwards in terms of user interface functionality. As Rich Carickhoff explains (see "A New Face for OLAP," page 24), the first browser-based OLAP front ends relied purely on HTML. Hyperlinks work fine for drilling down to greater detail and returning to higher level summaries, but HTML alone cannot perform more OLAP-like activities (such as rotating a cross tabulation using a mouse drag action). I have not forgotten that these features, which we take for granted in old-fashioned Windows or GUI-based applications from the Jurassic client/server era, were loudly trumpeted by OLAP vendors when OLAP began attracting mainstream attention just a few years ago. Yes, second-generation Web-OLAP products will use Java and ActiveX applets to restore client-side user interface features. But be aware that while Web-database integration technology is maturing rapidly, many implementations are still immature. Look before you leap; the drop could be quite steep.
Object DBMS vendors hope that the Web is the application that will sweep their servers into the mainstream. Their arguments are compelling: Many data elements that comprise sophisticated Web sites are complex objects intertwined in complex relationships that cry out for the advantages ODBMSs offer. In the shadow of this opportunity lurks an even greater threat. Relational DBMS vendors are offering object/relational servers that -- although not pure object-oriented DBMSs -- may be good enough for many customers who will have one more reason to stay off the ODBMS bandwagon.
What kinds of database servers will drive your next Internet or Intranet application? Of course, you should integrate your relational databases when doing so would provide benefits to users at an acceptable cost to administrators. If you already have OLAP, text, or object databases, providing access to users running a Web browser is getting easier and better. If you have been reluctant to investigate or embrace these non-relational database servers, now is a good time to reconsider. Tomorrow's data environment will almost certainly store more complex data. Despite the hype about new "Universal Servers," matching specialized servers to specialized kinds of data still makes sense in many situations.