Re: First Impressions on Using Alphora's Dataphor

"Paul G. Brown" <paul_geoffrey_brown_at_yahoo.com> wrote in message news:57da7b56.0408301732.c200bd5_at_posting.google.com...
> lajos.nagy_at_gmail.com (Josh Hewitt) wrote in message
news:<1c92edeb.0408260910.60242a59_at_posting.google.com>...
> [ snip ]
> > What if major vendors 'do get it' but enterprise environments simply
> > 'squeeze out' anything but atomic types (numbers, character strings,
> > booleans, etc.) from the database?
> [ snip ]
>
> The dumbest idea in 'database theory' is that 'relational theory' is
> about how to build 'databases' (and therefore that the way to advocate
> for the 'relational model' is to bash SQL DBMS products, multi-value
> DBMS products, and so on).
>
> The Relational Model describes a 'reason machine'.
>
> If you want the SQL:
>
> UPDATE Emps E
> FROM GetSalaryPopupWindow G
> SET Salary := G.New_Salary
> WHERE G.Name = E.Name
> AND G.Old_Salary = E.Salary
> AND G.UI_Device = CurrentUserUI;
>
> Emps E is a 'table'.
>
> GetSalaryPopupWindow is a 'relvar' that gets its values by popping up
> a UI window populated with E.Name and current E.Salary into the device
> indicated by the CurrentUserUI, and once that window is closed,
yielding
> a 'New_Salary' value back to the query.
>
> Or
>
> UPDATE Screen S
> FROM File F
> SET S.Pixel = F.Pixel
> WHERE S.X = F.X
> AND S.Y = F.Y;
>
> There is *nothing* in the relational model that precludes doing this
kind
> of thing. There are inhibitors in the minds of relational thinkers, who
> for too long have been fighting a battle they lost in their youth, over
> and over and over again.
>
> Forget databases, guys. They're dead. Dead as the dodo.

Hi Dr. Brown:

I certainly respect your knowledge and opinion, but I'm not sure I agree to the degree you state databases are dead. The examples you give are certainly possible and even already implemented, especially in tightly coupled integrated forms and reports environments with DBMS's. However, there still seems to be difficulty in convincing procedurally-oriented and constructionist-oriented developers in the usefulness of declarative manipulation across code/platforms/and data sources.

We've seen a great deal of research in mediator architectures and other "integrating" technologies over heterogeneous sources (files, OODBs, hybrids, hierarchical, and the like), but I have yet to see something that comes close to overcoming the NP-complete nature of the problem. During the time (a small amount and in an academic context, granted) I spent looking and researching developments, it seemed pretty clear that you can't use an integrating/reconciling technology based on logic if the sources don't necessarily follow any logic (that is easily and explicitly translatable). You simply can't make the illogical suddently logical without making a lot of assumptions, where half the time they might be correct and half the time they might not be.

I've seen other papers written (such as Bernstein as a follow-on to 'Too Much Middleware') that predict that middleware will evolve and merge various technologies (data management, portal, IA, etc) further into a very small set of monolithinc super-integrating technology products, and sometimes the trend seems to support this notion. But, still SQL DBMS technology seems to be thriving and the individuals around me seem comfortable with some sort of decoupling of a single application from data, especially in consideration of a larger enterprise context.

Could you give more concrete examples of what upcoming technology theories/implementations are leading to the impending raising of the independent DBMS tombstone? Thanks.

• Dan