Re: foundations of relational theory?

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:1Ypmb.23974$HS4.92369_at_attbi_s01...
> Hypothesis: PICK systems work well for application development
> because of excellent application development tools and tight
> integration between the application language and the DBMS.
> Agility is enhanced by the fact that some of the more complex
> possibilities for data models, such as many-to-many relationships,
> are simply excluded. In contrast, SQL DBMSs, while having a superior

This is a fascinating post and for me contains many truths. I will attempt to address the issues raised herein in the context of OpenInsight32 - a native Windows Applications Development environment containing many of the same features of Pick and other MVed systems. As such some of what I posit may not be true for all Pick systems but I am sure that for the most part there is no reason it canot be made such.

Let me start by acknowledging that - hoary old saws notwithstanding - that the MV market has not had the marketing clout of the more mainstream DBMS products. Thus we tend not to appropriate academic theses and pretend that our models instantiate them. To give a simple example which those who were present in the PC market in the early '80s can attest - Revelation had a direct market competitor dBase II. I remember discussions with the then management of Cosmos asking why, if dBase II could market itself as "relational" - which it did - why could Revelation not do the same. After all dBase II was so patently NOT relational that if they could do it we could. The reply was simple "because that would be untrue - we share many of the feature of the relational model but we do not implement all of Codd's rules". The fact that nobody did was seen, at the time, a irrelevant. That did not stop insecure IT management rallying to the dBase flag as it ticked the relational box.

In the late '80s Revelation sold more SQL Server than Microsoft themselves - Revelation's unique architecture and superb 4GL lent itself well to applications development regardless of whether you chose to use the Pick style back end or SQL Server as a back end. So your proposition that Pick tools tend to have good 4GLs has some basis in truth.

Coming on to your statement

> Agility is enhanced by the fact that some of the more complex
> possibilities for data models, such as many-to-many relationships,
> are simply excluded.

I have to disagree. We can instantiate one to one, one to many, many to many, one to many WITHIN THE SAME TABLE, many to many WITHIN THE SAME TABLE etc etc. Thus it would be possible (and likely in most implementations) to be able to perform a single disk read (which given the effectiveness of Random Access Hashing would take on average less than two disk accesses) and have in memory a single row containing

    Columns containing normalised data
    Columns containing lists of foreign keys to another table/tables     Columns containing lists of foreign keys to rows within the current table (parent child relationships).

Thus I could (and I not saying I _would_ design this way) read in a Sales Manager Row and have to hand with no further external joins

    The demographic information about the sales manager     A list of foreign keys of this individual's subordinates within the same Bod table

    A list of foreign keys of this individual's managers within the same Bod table

    A list of foreign keys to the accounts handled by this individual     A list of foreign keys to all invoices generated for all accounts handled by this individual

    A list of all phone numbers for this individual along with phone types (why store this data atomically?)

    A list of foreign keys to all the posts this individual has held     A list of this individual's children's names and birthdays for that touchy feely manegement style

    A list of foreign keys to this individual's company cars     A list of this individual's preferences for bonuses along with dates awarded if appropriate

    etc etc ad infinitum

and these foreign key lists would be maintained at a domain level by triggers - not at an application level.

Now obviously once I have taken the decision not to store data atomically I lose some flexibility for future reporting but so what? I don't mean that flippantly but in the context of the application above I will never have a requirement to find all staff who have a child called John born on the 4th of July so why normalise this information? If I had no choice OTHER than to normalise I could understand why I would do it but given the choice I would not. Now the argument may be advanced that in 5 years time I might wish to have stored this data atomically. If that is the case then fine - normalise it then - it's not rocket science. In any case in practice after 5 years there will be a new platform and new software and management will want to migrate in any case. Stasis is not in the best interests of senior IT management. It is in the best interests of the user/client.

As to the contention that SQL lacks a good 4GL I cannot comment as I have little experience of working with such tools. Most of my SQL work was in the late '80s. I do know from practical experience that the majority of clients we deal with find applications development under OpenInsight a lot faster than under "Relational" systems. As an example (a real example with references if needed though not on a newsgroup) one of my clients was asked to put together a paper for presentation in 2 weeks to the board on why they should go the OpenInsight route. Two other sets of colleagues were similarly tasked for Oracle and SQL Server. At the board meeting my client's colleagues presented their papers and my client presented the finished system - commercially finished and now in live production. At another site (a very large financial institution) the SQL Server solution has been under development for over 3 years. As development continues and deliverables slip, more and more of the product is descoped and reassigned to the OpenInsight system. The argument seems to be "deliver it in OpenInsight but plan to move to a 'strategic relational' system long term". This is similar to the argument advanced to me by the Inland Revenue in the late '80s - "when we want to be able to DELIVER we use Revelation but our STRATEGIC platform is the ICL One Per Desk".

I would contend that OpenInsight already provides the tool you describe - I can use it's toolset against native Linear Hash tables (I would not claim this to be as scaleable as Oracle but if you only need a few hundred concurrent users with a few tens of millions of rows it works well enough) against native Oracle, SQL Server and Lotus Notes or against any ODBC data source. Normally I choose to use the native back end - it is self contained, requires no complex installations can be run from a CD if required. The licensing model is incredibly cost effective (free single user runtimes, and a per seat cost as low as $20 with no annual maintenance) and it comes web aware out of the box.

Personally I have no anti-relational axe to grind - there are applications that I believe it is better suited for - but for SME solutions and vertical markets I believe it is difficult to challenge the MV cost/benefit ratio. Received on Sat Oct 25 2003 - 13:38:35 CEST