craig@gpu.utcs.utoronto.ca (Craig Hubley) (09/03/89)
Does anyone know of a(n) SQL implementation for the Amiga ?
Or in fact *any* relational database for the Amiga ? I don't
expect to find AmigaOracle, or anything, but even an unoptimized
PD source (GNU-SQL ?) or something would do. Things are getting
desperate, I have to find one or relegate the Amiga to terminal
status and save my sheckels for something that can run a database.
Craig Hubley
--
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.bitnetbjc@pollux.UUCP (Betty J. Clay) (09/03/89)
In article <1989Sep2.175104.12276@gpu.utcs.utoronto.ca> craig@gpu.utcs.utoronto.ca (Craig Hubley) writes: >Does anyone know of a(n) SQL implementation for the Amiga ? >Or in fact *any* relational database for the Amiga ? I don't > >Craig Hubley SuperBASE Professional is a relational database with its own programming language - not SQL. I don't know for sure, but I believe that DataRetrive Professional, from Abacus, is also relational. Betty ---------------------------------------------------------------------------- Betty Clay ...texbell!pollux!bjc CompuServe 76702,337 ---------------------------------------------------------------------------
usenet@cps3xx.UUCP (Usenet file owner) (09/03/89)
In article <1989Sep2.175104.12276@gpu.utcs.utoronto.ca> craig@gpu.utcs.utoronto.ca (Craig Hubley) writes: >Does anyone know of a(n) SQL implementation for the Amiga ? >Or in fact *any* relational database for the Amiga ? I don't >expect to find AmigaOracle, or anything, but even an unoptimized Yes and no. No SQL, but SuperBase Professional is relational. It is the only database that I have ever used, so I cannot compare it to other databases. It does support linking multiple databases together by a common element. It has a complete language and built in editor (not so hot editor). The language is Microsloth BASIC style with database extensions. You need at least 1meg to think about running it. It also includes a forms editor to create custom graphic displays or printouts. You can include external documents, pictures and sounds. Fairly well amigatized. It has versions for GEM, and Atari, but not MessyDos (which is probly why it is well amigatized). No copyprotection in the latest most expensive release. REAL NAME: Joe Porkka jap@frith.cl.msu.edu
kelso@mimsy.UUCP (Stephen Kelley) (09/03/89)
In article <1989Sep2.175104.12276@gpu.utcs.utoronto.ca>, craig@gpu.utcs.utoronto.ca (Craig Hubley) writes: > 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. Please note that I have a "day job", so this is a part time effort. 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. -- Real: Stephen Kelley, Welch Library, Johns Hopkins Univ. Internet: stevek@welch.jhu.edu
craig@gpu.utcs.utoronto.ca (Craig Hubley) (09/03/89)
I keep this public in the assumption that lots of people are interested in this. If not, please let me know. From the looks of things, there won't be many responses anyway... In article <4435@cps3xx.UUCP> porkka@frith.UUCP (Joe Porkka) writes: >> (I write) >>Does anyone know of a(n) SQL implementation for the Amiga ? >>Or in fact *any* relational database for the Amiga ? I don't >>expect to find AmigaOracle, or anything, but even an unoptimized > >Yes and no. No SQL, but SuperBase Professional is relational. > >It is the only database that I have ever used, so I cannot >compare it to other databases. The key to 'relational' is whether it is set-at-a-time and obeys the relational algebra. Many systems claim to be relational but in fact are not, dBase for example. The reason this is important is because I have a very large body of complex data that I can't forsee all the indexing combinations. I intend to keep this in true relational-normal format for eventual conversion and compatibility with SQL, so in dBase terms I would be constantly joining several databases together, which takes weeks in that bogus system. It's not a matter of simple stepping-through records. I actually need relational capabilities. I mention this because the word 'relational' has been thrown about very freely by marketeers and it just isn't true most of the time. >It does support linking multiple databases together by a common >element. It has a complete language and built in editor (not so hot >editor). The language is Microsloth BASIC style with database >extensions. You need at least 1meg to think about running it. This sounds much like dBase, sigh. I was hoping at least to find something with a C interface so I could use C++ for my weirder stuff. I understand SuperBase has Arexx support, though... >It also includes a forms editor to create custom graphic displays >or printouts. >You can include external documents, pictures and sounds. Fairly >well amigatized. How do you 'include' external documents ? Filenames ? hypertextish links? >It has versions for GEM, and Atari, but not MessyDos (which is >probly why it is well amigatized). That's encouraging. >No copyprotection in the latest most expensive release. That's also encouraging. What's it cost ? >REAL NAME: Joe Porkka jap@frith.cl.msu.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
craig@gpu.utcs.utoronto.ca (Craig Hubley) (09/03/89)
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
bjc@pollux.UUCP (Betty J. Clay) (09/04/89)
In article <4435@cps3xx.UUCP> porkka@frith.UUCP (Joe Porkka) writes: >In article <1989Sep2.175104.12276@gpu.utcs.utoronto.ca> craig@gpu.utcs.utoronto.ca (Craig Hubley) writes: >It has versions for GEM, and Atari, but not MessyDos (which is >probly why it is well amigatized). >No copyprotection in the latest most expensive release. >REAL NAME: Joe Porkka jap@frith.cl.msu.edu But there IS a version of SuperBASE for the MS-DOS machines! I believe it is called SuperBASE 4 (or maybe they are up to version 5 by now). SuperBASE comes from an English company, Precision Software. THey have an office in Irving, TX. to serve the US. Precision Software 8404 Sterling St, Suite a Irving, TX 75063 214-929-4888 Betty --------------------------------------------------------------------- Betty Clay ....texbell\!pollux\!bjc CompuServe 76702,337 --------------------------------------------------------------------- .