Different Reasons People Like Relational

Different RelationalWeenies seem to emphasize different aspects of relational. This is an attempt to catalog the reasons.


On being "Standardized":

RDBMS and relational have provided a somewhat standardized way to represent information and associations between it. (However, there are sometimes disputes over the level of normalization.) Also, SQL has become a common semi-standard across different RDBMS brands. Thus, one can query without learning a new query language from scratch. (Many feel that SQL is far from the ideal query language. However, that is a typical trade-off of standards).

SQL is an ANSI and ISO standard. See http://en.wikipedia.org/wiki/SQL#Standardization

Adherence to published standard by vendors varies, and also there are allegedly some fuzzy areas to the standard. One could also perhaps argue that the standard is unnecessarily complicated.

On the benefits and drawbacks of "Ad-Hoc Access to Data"...

It's still an open question as to the relative benefits and costs of enabling ad-hoc access to operational data stores.

Benefits: Costs: Note that one does not have to allow users access to ad-hoc queries, or could restrict their queries to a limited set of views or stored procedures. Thus, these are not really a downside of relational per se. Perhaps another way to state the benefit would be "relational can provide powerful ad-hoc query ability".

On the "They don't know anything else" comment:

Really (They like relational but) have they tried something else or do they quickly dismiss everything that is not relational? Do they know that SqlFlaws are not part of the RelationalModel and a better language than SQL could be used (TutorialDee)? Do they bother to try an ObjectRelationalMapper? Do they make detailed comparison with ExBase? Have they (really) experimented Cobol? Have they used Prolog? Do they (really) know the advantages/disadvantages of a HierarchicalDatabase? Do they bother to compare SQL it with ConceptualQueries? or with JPAQL? or with OQL or OCL? or they just follow along because "Everybody who is anybody around them likes Relational". See OldRulesWithForgottenReasons

This could apply to anything, and thus should not bother being mentioned here in my opinion, other than maybe a brief reminder. Instead it rambles with a hint of insults.

I am sorry if it was interpreted as insulting,that wasn't my objective. I think it is important to remember the difference between something that is known to be superior, and something that is believed to be superior because of tradition (the principles in the tradition may be inherently superior, but I think that it would be better to explain people the concrete advantages, instead of just saying "this is the best way, because we have always done it this way and it is the only way we know"). See TraditionOverridesProof

Quite a ramble. But I'll touch on some of its points anyway:
On the ease of doing "Ad-Hoc Data Processing":

(The discussion in this section originally started with two points: "Do they make detailed comparision with ExBase?" and "Are you really suggesting that corporations should discard Oracle, DB2, Sybase and SQL Server, in order to standardize all work on dBASE clones?" )

{I don't recommend it to replace Oracle etc. for "corporate data". The above is a red-herring. Where it shines is ad-hoc processing and temporary tables, such as client-side processing. It is one of the best tools for building one-shot data conversion scripts, for example. --top}

There's A LOT to be said for quick and easy generation of CreateReadUpdateDelete screens to let users easily see and change business data. I think we could learn something important from RubyOnRails and like-minded frameworks. I see a lot of value in the TheNakedObjectsFramework, too. -- JeffGrigg

View edit of March 18, 2010 or FindPage with title or text search