resolution of the inside/outside RDBMS dichotomy (was Re: Some Hype on "new" databases)

"Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message news:u69kk2-v82.ln1_at_pluto.downsfam.net...
> Be warned, don't read this one on a full stomach:
>
> http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=293

Despite poor reviews by others, I thought the article highlighted some fundamental operational concerns that are probably outside the current paddock of theory.

...[trim]...

> Perhaps this is the most fascinating, with the admission that there is no
> general solution for workflows:
>
> "The key question facing researchers is how to structure workflows.
> Frankly,
> a general solution to this problem has eluded us for several decades.
> Because of the current immediacy of the problem, however, we can expect to
> see plenty of solutions in the near future. Out of all that, some clear
> design patterns are sure to emerge, which should then lead us to the
> research challenge: characterizing those design patterns."

The obvious problem here is that there does yet yet exist a recognised theory in which the organisation has its place. I am confident that this will soon emerge from an extention of the relational model of the data in which the data (at long last) is perceived to be OWNED (always) by an organisation and the valid latent implications are resolved.

That what is being modelled is organisational data in every single instance not only of modelling, but all phases from conception through to implementation, maintenance and development of a production system.

At that stage, (generic) organisational structure will be examined and found to be amenable to simple forms and tables, and once this point is reached, you already have the workgroups for which work-flow have atomic meaning, context and operation.

Here in the final section of that article is the sentence that interested me the most (re: future developments)

"The beauty of this, of course, is that the whole inside-the-database/outside-the-database dichotomy that we've been wrestling with over these past 40 years is becoming a thing of the past."

I have already made some comments on this aspect of the field, in threads with a subject's related to the word "internalisation" or "internalization" last year.

You see, in 2001 I created a tool (not called Andomeda but "LittleSteps") by which I resolve this dichotomy by obviating the environment outside the database. Apps are developed in SQL alone and stored inside the rdbms as stored procedures, managed by a menu stored proc that has reference to an organisational structure table and the application register (all the defined procs).

SP's may be easily "chained" together to provide n-level drill down functionality from summaries, to intermediate summaries, to detail, to history, to logs, when required, so the solutions are very very sophisticated but very simple with bare-bones minimal of moving parts.

There is no code external to the database in this solution except for the Littlesteps tool, which is best described as rdbms portal software providing a service level interface between the RDBMS and the end user in a workgroup within an organisation.

The application software is delivered as a database. Total development work is within SQL and the data. Nothing exists external to the RDBMS except this tool.

Since 2001 I have been selling solutions using the tool as my business in Australia, and it has done well for the small amount of time and effort that I have invested.

Thanks for the reference, but we in Australia have often gone onwards to future solutions oblivious to the rest of the world resident in the antipodes ;-)

Best wishes,

Pete Brown
Falls Creek
Oz
www.mountainman.com.au/software Received on Wed May 04 2005 - 02:18:15 CEST