Page #95 (Chapter 14 - Whats Next?)

	Chapter 14 - What’s Next?
	Visual Basic Developers Guide to ASP and IIS
	A. Russell Jones

Copyright 1999 SYBEX Inc.

---

	What about Database Technology?

	Databases are as important to Web applications as files are to stand-alone applications. As applications become centralized, they need to put user-specific information somewhere. Files work well when you need only a few of them, but quickly become unwieldy when you work with thousands of them. Even desktop operating systems are likely to dispense with files as we know them now and begin storing content in a database instead.

	There are two major trends in databases: keeping information in-memory, where applications can reach it faster, and changing the storage and technology so you store objects rather than data. You've seen both techniques in action in this book (although not with databases). Maintaining state via Session variables is similar to the idea of in-memory databases (IMDBs). Rather than write the information to disk, you cache it in RAM. Storing information in memory can speed up operations by several orders of magnitude. Similarly, when you use the PropertyBag to store binary object data, you can reconstitute the object itself from the stored information, not just the data. This technology should be commonplace already, but it's not.

	Several IMDBs are available today. Microsoft provides a limited IMDB with Windows 2000 COM+ services. I think you'll find that the popularity of IMDBs rises as memory prices fall. Note that those costs are already low enough for the technology to be useful. In the future, you'll see massive databases that use disk storage only for backup—all database operations happen in memory. IMDBs are especially important to Web developers. In keeping with the theme of this book, you can get the data and get out more quickly than ever. Session variables become obsolete when you have an alternative that's just as fast and has the added advantage of permanence, with no extra coding. Consider this: If you can store state permanently, yet retrieve it nearly instantaneously, you don't need sessions. A user's "session" begins at registration and ends—well, never! At least, until you run out of memory. Seriously, you may need to retrieve a person's state from disk, but once retrieved, you can access it much as you do Session variables now.

	Object databases are likely to become much more common. Today, you must either code repetitively or use modeling tools to get data out of databases and into objects. You must assign data to properties to re-instantiate objects, and you must assign properties to database fields to store objects. Consider an object with 15 or 20 properties (not an uncommon figure). Today in VB it takes roughly one line of code per property to save and retrieve the object. That's 30 to 40 lines of code! Wouldn't it be much more convenient to write code like the following instead?

	Set myObject = "SELECT myObject FROM myObjects"

UPDATE myObjects WHERE myObjects.ID = myObject.ID

	You'll be able to do that before too long—probably not with that exact syntax.

	In the meantime, you might consider looking at XML databases. XML databases store not only data, but also the structure and relationships of that data. Relational databases also store data and relationships, but the relationships are separate from the data. Relational databases store structure as well, but in an extremely rigid manner: by imposing an artificial order or sequence for data. There's no particular reason why you should have to store a LastName value in column 1 and a FirstName value in column 2, except that relational databases enforce position as a means of capturing structure. In contrast, an XML database "knows" which item is the last name; the structure is part of the data. Columns become irrelevant. As XML becomes more common, so will XML databases.

	You can already store ADO Recordsets to an XML file and re-instantiate them later. Code like that will make objects such as the CStoredRecordset obsolete as well. Sure, the ADO Recordset takes more resources, but it also provides more services. You can save an ADO Recordset onto a client, let the client modify the Recordset, then return the XML string to the server for centralized update. When Recordsets aren't too large, they can function as miniature, persistable databases. Today, we perform a tremendous amount of processing to put information into databases that are often mutually incompatible. It is relatively easy to foresee that keeping the information in XML form will be an advantage, both in portability and in processing power.