Today, the foundation of most of our custom-built systems is a relational dbms. While development frameworks vary, they overwhelmingly access and maintain data in relational tables and columns. As I write I routinely save this post in a MySQL database, and at work I tend SQL Server applications. Millions of others develop, use, and extract analytical data from thousands of SQL Server, DB2, and Oracle applications, on servers and networks maintained in-house by in-house administrators.
Some claim that the relational dbms may be out of style very soon. Cool new “cloud computing” and “SaaS” apps and services delivered over the internet seem to be popping up everywhere – just look at Salesforce.com, the well-established Customer Relations Manager vendor, and the many cloud-based PC backup sites. As part of that trend, Amazon, Google, Microsoft and others offer database services over the internet that don’t look much like relational dbms’s. Some supporters of the cloud-db options seek alternatives to the standard relational DBMS (note this widely read article). Of these, many are OO developers. There’s a fundamental dissonance between OO and relational approaches, requiring an intermediate object/relational mapping (ORM) layer for OO systems to operate effectively with relational DBMSs. Many of the new cloud-db options are open source, lightly structured data services provided via the internet, capable of storing and delivering large data stores for high availability, fast response applications.
The convenient thing about relational databases is that they pretty much match the business view of data, and therefore give business people and developers common ground. A well thought out relational data model is one way to express the inherent structure of business rules (see this previous post). A relational model at the back end of a custom-built system means that both developers and business people can talk about the real guts of a system in ways that make sense to both, like this:
- Developer to business person: “Should we allow a part_order to include items from only one division”
- Business person to developer: “After a call from our shipping department, I ran a query on the part_order table and found a that there is a part_order with null shipper_phone_number. I thought it was a required column, what’s up?
How’s it going to be when those comments don’t reflect the underlying structure of the database? Today’s cloud db offerings vary in structure, but tend to favor highly efficient and flexible models like name-value pairs, and avoid the overhead required by semantic layers like the relational model. According to the MongoDB site, “by reducing transactional semantics the db provides, one can solve an interesting set of problems where performance is very important.”
In such databases the structure of the data will be hidden from business people; there will be no shared business/IT view. Rather than talking with business people about the actual database structure we’ll talk about its custom abstraction, and when things go poorly with performance and functionality the developer will in effect say “trust me on this one” to the business person rather than explaining what’s up.
For a long time cloud databases will be another option alongside the relational model, but the more prominent cloud databases become the more difficult it will be for developers and business people to communicate about business data in IT applications, and it could be a serious challenge for developers to learn to cross that communications gap without the bridge provided by the relational model.