Checksum: 56386
Path: utzoo!utgpu!craig
From: craig@gpu.utcs.utoronto.ca (Craig Hubley)
Date: Sun, 3-Sep-89 16:41:29 EDT
Message-ID: <1989Sep3.164129.6544@gpu.utcs.utoronto.ca>
Organization: University of Toronto Computing Services
Newsgroups: comp.sys.amiga
Subject: Re: SQL (or other relational) databases for the Amiga
References: <1989Sep2.175104.12276@gpu.utcs.utoronto.ca> <19396@mimsy.UUCP>
Reply-To: craig@gpu.utcs.UUCP (Craig Hubley)

In article <19396@mimsy.UUCP> kelso@mimsy.UUCP (Stephen Kelley) writes:
>> (I write)
>> Does anyone know of a(n) SQL implementation for the Amiga ?
>
>Reply (sort of)
>I'm in the process of porting RUBIX(tm), a fully relational db
>(algebraic query lang, not SQL, yet) from the UNIX(tm) world
>to AmiDOS.  It only has a command line interface so I'll have to do
>a *real* interface for it.  Since I'm still early in the porting 
>phase I'd like to hear what netlanders would like.

Well, this is more like it.  First of all, if you want to do a real
interface, first of all please leave the command line interface intact.
Build whatever you want on top, but if you compress front-end queries
down to this command-line syntax, you will have a quite low-bandwidth
query and data expression language ready-made to use over networks, etc.

I actually prototyped a system much like this for the Amiga back in '85.
When we determined it would cost far more money to get it to market than
we had, we decided not to finish it.  Sad realities of the marketplace,
finding investors for software projects at the time was simply impossible.

What we did was this:  Assuming SQL on a server and a physical network
connection, build an Amiga front-end that builds and displays queries,
communicating with the back-end as SQL.  What we really did was write
a relational algebra notation and then add the icky SQL syntax.  This was
only one part, the rest was a relational-engine-written-as-relational-forms
so that the engine itself could be reconfigured on the fly as required.
If this sounds flaky, realize that IBM is now selling this, with an updated
relational algebra, as DB2.

Ideally, the interface to your engine should be as much as possible like
the raw relational algebra.  Some sickos, like me, would actually use this,
and a bloody powerful tool it can be, too, each line is like 50 in dBase code.
SQL is one (standardized) front end to this algebra, which more people would
use.  For a graphical interface, you could work with visible sets and their
intersections, kind of a Venn diagram language.  This would compile to the
relational algebra, and whatever was received back would become a new set.
Every query would still go through the relational-algebra stage.  Another
interface could be through ARexx, or even through the Linda service broker
that I described earlier.  Forms (the usual user interface) could be
defined as a relational table themselves, as are Views, the intermediary
between Tables and Forms and where most relational processing takes place.

The architecture would look like this:

RUBIX <-(raw queries)-> me and other lunatics
			<-(SQL layer)-> SQL commands and files
			<-(view builder)-> visual relational programming
			<-(form builder)-> visual relational data management
			<-(ARexx interface)-> ARexx scripts to do DBMS ops
			<-(C interface)-> C and C++ programs doing DBMS ops
			<-(Linda interface)-> universal query/response paradigm
			  (would be ideal for working across networks, too)

In fact if everything were to work through the Linda interface, that would
probably be by far the cleanest and easiest solution, since then any language
interfacing to the Linda tuple space could issue DBMS queries and updates
from there.  If I could get a copy of the RUBIX algebra I might be able to
give you some ideas.

> Please note that I have a "day job", so this is a part time effort.

The nice thing about client-server architectures like the above is
a) they are perfectly suited for multitasking machines like the Amiga
b) they are scalable and easy to implement in stages

>I worked for the company that produced the UNIX(tm) version & have signed
>"non disclosure" stuff so this can become a real db for Amy if there
>is enough interest.

Consider me interested.  The only reason I didn't do this in 1985 was money.
We thought the market was there, but digging up a million bucks to chase it
was beyond my capacity at the time.  If nothing else, such a system would
mesh ideally with the hundreds or thousands of Amigas that will soon be
used mostly as Xwindows terminals to Unix boxes... imagine the first decent X
interface to a real relational DBMS, running on an $800 machine to boot!
Commodore should be screaming to have you do this.

>Real:	Stephen Kelley, Welch Library, Johns Hopkins Univ.
>Internet: stevek@welch.jhu.edu

    Craig Hubley			-------------------------------------
    Craig Hubley & Associates		"Lead, follow, or get out of the way"
    craig@gpu.utcs.utoronto.ca		-------------------------------------
    craig@gpu.utcs.toronto.edu    mnetor!utgpu!craig@uunet.UU.NET
    {allegra,bnr-vpa,decvax,mnetor!utcsri}!utgpu!craig    craig@utorgpu.bitnet

-- 
    Craig Hubley			-------------------------------------
    Craig Hubley & Associates		"Lead, follow, or get out of the way"
    craig@gpu.utcs.utoronto.ca		-------------------------------------
    craig@gpu.utcs.toronto.edu    mnetor!utgpu!craig@uunet.UU.NET
    {allegra,bnr-vpa,decvax,mnetor!utcsri}!utgpu!craig    craig@utorgpu.bitnet
