The Grand Unified Database Theory

Everywhere you turn these days, it seems you're dealing with a database.

If you want to be state of the art, the inventory in your Web store should be in a database. The same is true of your customer list, and your prospect list. The reports delivered by Web server logs or held by your ad agency are databases. You target ads by matching these databases against other databases. Personalization engines are all about databases. Even e-mail lists are databases.

In the end this will be very good, but we need to stop and do some hard thinking first. Right now it takes work to connect databases. You can move data between them with Open DataBase Connectivity (ODBC) but that takes time, and time on the Web can quickly turn into lost business. So, NetPerceptions, a leader in personalization software, moved last year to offer "native" support for Oracle (Nasdaq: ORCL), Microsoft (Nasdaq: MSFT) SQL Server, and other leading databases, rather than making customers lean on ODBC calls. If you're going to put a database call into a customer's hand, look for native support.

But there's another problem with databases, even if all the databases you use are written with the same software. That is mapping the fields. Some databases may put the name of the customer first, others a number, still others may lead with a product. If you don't want to compare names to addresses, you have to properly match the fields in Database A to those in Database B and, again, that takes time. This makes connecting databases expensive.

What's needed, then, are standards, and what I call a "grand unified database theory" that lets databases interoperate more easily across all Web platforms. The good news is that people are working on these problems, through the XML group and, believe it or not, in the government, which is drowning in databases. For the sake of everyone's Web business, I wish them Godspeed.

What do you think? Let's talk about it.