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