Thursday, September 22, 2005

Paradigm Wars

I am about to poke my vulnerable toe into the ancient cauldron that is the relational-verses-object paradigm debate. But first of all, let’s get a few definitions straight.

- The relational model is a pure mathematical theory for modelling data, which is loosely based around set theory. It offers a formal and elegant approach to data structuring together with a broad (but unspecific) framework for how data is manipulated. It is not SQL. It is not a database.

- The object model (separated from any specific language) is a rigorous model for software development that cohesively ties data with processing. It is not a language. It is not C++, C#, Java etc. It is not a database.

- A database is a piece of infrastructure for managing and persisting data. Nothing more. It may present a particular paradigm view of the data (such as relational, object or XML), but for pragmatism and performance reasons, it’s actually quite unlikely store its physical data in an exact extrapolation of the paradigm used at the presentation level.

- SQL, C++, C# and Java are languages that purport to conform to their respective paradigms – but they all have weaknesses to a greater or lesser degree.

If you disagree with any of the above definitions then please don’t bother reading any further as I suspect you have some personal subjectivity issues you need to deal with first... :-)

The relational model is good for achieving clarity in the data structure. It is excellent for environments where users need to discover and understand the structure of the data. However, sadly, SQL is a poor language for exploiting the relational model as it violates/disregards some of its most fundamental principles. Frankly, it is wholly inadequate for the task and many of the problems encountered with relational systems arise from the failings of SQL itself. The relational model is beautiful - SQL is not. If you doubt this, then compare a SQL statement with the simplicity of what it is trying to achieve. I suspect SQL dumped the elegance of simple relational operators in favour of “natural language” and ultimately failed at implementing either satisfactorily. Users do not struggle with the simple concepts of a joins and grouping, but they do struggle with SQL’s clumsy and arcane representations of them.

Meanwhile, the object model is a good framework for both data and process development, that incorporates rigorous principles such as encapsulation, inheritance and polymorphism to promote development productivity and to provide protection against potential implementation mistakes. However, it deliberately hides data and does not provide open visibility of the data structure for users unfamiliar with the system construction who are attempting to discover it – users must rely on the software implementation to provide a suitable presentation. The object languages available do a reasonable job of implementing the object framework for development purposes, although each has its own specific issues that detract from the rigours of the underlying paradigm to some extent.

Both relational and object paradigms have strengths in different areas and an attempt to combine them at a fundamental level is highly desirable in order to achieve the open formality of relational structures under the protective framework of object oriented development. The current attempts to combine object and relational models into a single database are really just clumsy attempts at shoehorning objects into relational databases – and is a far cry from the fundamental rewrite that the industry needs. Hopefully, someday we can free ourselves from the monster that is SQL and, with luck, that may coincide with a new language that elegantly and efficiently combines the best principles of the distinct paradigms that exist. None of these paradigms are mutually exclusive – it is the bigots that hail their particular paradigm’s singular divinity that create barriers to a better approach.

Finally, database performance has nothing to do with these paradigms. If a database is performing badly then that is largely irrelevant to whether it offers a relational, object or an XML view of its data – the issue sits with the database architecture and not the paradigm.

Now... can we all move on and do something better please...


Anonymous Anonymous said...

This comment has been removed by a blog administrator.

12:38 PM  

Post a Comment

<< Home