Daily Archives: June 1, 2004

SQL is Dead

Last week while talking with Frank Martinez during the BEA show (and this is really one of the great things about my job, that I get a chance to meet and talk with interesting people like Frank), I started on a version of my mini-rant about SQL and GUIs being labor-draining anachronisms. Frank basically agreed, and that’s about all the encouragement I need to try to write it all down here ;-).
The point is that it just takes too much time and effort to design, develop, and adminster a database and associated GUI. Who can really afford to take on all the data modeling, normalization, and structuring work necessary to define a sensible database and usable GUI?
The benefits seem very small given the huge amount of effort. After all, most database applications just extract the variable data items from the static fields, figure out how to store them in the database, and then retrieve them so they can “rehydrate” them back into the GUIs from which they were extracted.
This all started when storage space was tight in the early days of business computing, when every byte counted and we (all) did things like store “82” instead of “1982” and measured program load sectors in 16K chunks (for example). Processing power was non-existent on the desktop, and even the servers were constrained. Data and its presentation needed to be managed carefully to maximize hardware and software capacity.
Today storage space is essentially free, and there’s an abundance of cheap and available processing power from the desktop to the mid tier to the back end. Why not just store the data along with its formatting information in an XML file and just render it when it needs to be displayed or interacted with? Just store everything — variable and static — in the XML documents and XML Forms and eliminate all that unnecessary database and GUI design and development labor.
Of course, SQL is really no more dead than CORBA, Java, or the mainframe — at least not yet.
But there is no longer any good reason to assume that structured data is the right solution for every data management problem. A large number of applications manipulate data intended for use by one person at a time. A database and GUI application is really overkill for that.
On the other hand, applications like airline reservations and buying concert tickets will probably always need structured data, since they rely upon the ability to accurately manage shared access to a single data item instance (i.e. the airplane or concert hall seat) so that it is sold only once and on a first come first served basis.
Applications like purchase order approval, medical records distribution, expense report filing, engineering and repair drawing distribution, safety inspections, and so on, really do not derive any benefit from the significant effort required to structure their data.
These are also the applications that are increasingly important to “mobilize,” and structured data is not the right approach, not just because of the excessive labor involved, but also because the database replication and synchronization problem is basically unsolvable over a WAN.
This isn’t to say that structured data isn’t important, but it is more important for field workers to have the ability to orchestrate the distribution of unstructured, personal content to the right individual at the right time, and SQL just can’t do the job.