Business Connectivity Services in SharePoint 2010 preserve use of Relational Databases

I just finished reading an article on ITWorld talking about the Decline and fall of the relational database.  It’s an analytical review of various data models, object models, and information architectures minus any solid conclusion.  The article ends with what it calls a tentative conclusion as to it’s fall.  “I do not think that any one of the above camps can deliver a killer blow to the pre-eminence of the relational database but taken together, I think they have enough momentum to topple the giant.” Sean McGrath suggests.

SharePoint’s category in the article is “The chaoticians: Promote the benefits of ex-post-facto information structuring.”  In the same category is Google (for it’s search), Notes, and Autonomy.  While I enjoy the principal of we’ll figure out how to make sense out of our data after we get it there, I would suggest that while that model is very common in SharePoint it doesn’t have to be.  I’ve come across extremely structured SharePoint deployments.  The chaos of unmanaged deployments found valuable by the teams that use them for file sharing and collaboration bring stress to the information managers and IT management trying to get a handle on it. There are many preaching governance which sets up a plan to address the chaos and get everyone on the same page.  SharePoint ultimately provides read and write views and structure to both structured and unstructured data with a layer of authorization in a web interface.

Here’s my 2 cents.  In one ugly word it’s Mashups.  In three words,  it’s Business Connectivity Services.  SharePoint does bring together the unstructured and structured data and not only does it blur the lines as the author suggests, but it provides it up through search, and in SharePoint 2010 adds social elements of tagging, ratings, and meta data not only on the item, but enterprise policies and enforcement.  My design in this article isn’t to sell you on SharePoint, but to show you that the future doesn’t kill relational data.  It does move some of what is loosely relational and lightweigh applications building and moves it into SharePoint.  That which doesn’t move stays there.  Relational databases will not die, they will simply be exposed through various applications through full CRUD and CRUDQ applications.  SharePoint workspace even adds the ability to take data exposed through BCS through external lists, offline.

If you’ve spent any time with data structures in OneNote you’ll get a glimpse of the future of data in a single file.  (What’s new in OneNote 2010.)  Check out this video on multi user editing in OneNote 2010.  The OneNote database which has both structure and no structure at the same time as organized by the author.  You’ll see very clearly that data comes in very different types and formats and can be organized in views, audio, video, in objects, in shapes, sync to cloud, translation services, and drawings.  

In conclusion…

Users won’t need to care whether the data is a Wiki, XML, or Relational.  They don’t have to care if it’s a blob or an XML object.  They never have cared.  Those that design the applications will choose the right model for the data based on the need.  Just like SharePoint stores it’s data in SQL, SharePoint won’t replace databases and tables, it will simply continue to abstract them.  The layers of abstraction and the simplicity of doing so will only get easier.  A form for example might store it’s data in a sharepoint list, an XML file or blob, or in a database.  Designers will use a Designer tool (such as Infopath or SharePoint Designer) or word processor such as Word or OneNote or an online editor like Word or Online Web Application client.  The data structures are easily abstracted and becomes more irrelevant.