simmel@ginosko.samsung.com (Sergiu Simmel) (05/12/89)
I am trying to select a commercial RDBMS product to be used as a back-end
for a system we're working on. Here are a few criteria for selection:
* RDBMS should have a large enough share of the Unix(tm) RDBMS market;
* RDBMS should have a quality (stable, well designed, working, complete)
programmatic (3GL) interface (no pre-processors, such as ESQL, required);
* RDBMS should run on a variety of hardware platforms (Suns, Pyramids,
perhaps DECstations 3100);
* company should provide good technical support for 3rd party developers;
* company should provide adequate VAR program and support;
* RDBMS should have adequate performance;
* RDBMS should be compact in size and architecture.
Although there is no total order among these criteria, the importance tends
to decrease down the list.
Assuming that the result of applyting all these restrictions is not null,
what product would YOU select if you were me?
Please direct responses via e-mail to address below. I will post a summary if
relevant responses arrive. Thank you, in anticipation, for your effort and
responsiveness.
================================+==========================================
Sergiu Saul Simmel | Voice: 508-685-7200 x133
Senior Software Engineer | FAX: 508-685-4940
SAMSUNG Software America, Inc. | Internet: simmel@samsung.com
Computing Systems Division | UUCP: simmel@ginosko.UUCP
One Corporate Drive | CSNET: samsung.com!simmel@Tektronix.CSNET
Andover, MA 01810 | BITNET: samsung.com!simmel@Psuvax1.BITNET
================================+==========================================cs_bob@gsbacd.uchicago.edu (05/12/89)
In article <1089@ginosko.samsung.com>, simmel@ginosko.samsung.com (Sergiu Simmel) writes... > >I am trying to select a commercial RDBMS product to be used as a back-end >for a system we're working on. Here are a few criteria for selection: > > * RDBMS should have a large enough share of the Unix(tm) RDBMS market; > * RDBMS should have a quality (stable, well designed, working, complete) > programmatic (3GL) interface (no pre-processors, such as ESQL, required); .. No offense, but that seems to be a pretty arbitrary requirement to place second on a list ordered roughly by importance. Just as an example, you are technically ruling out any C based system, since C pre-processes macros by default. A stiff requirement indeed for a UNIX based system. I'm no expert on UNIX based DBMS systems, but if you're looking for a relational product that satisfies both of your first two requirements, I wish you luck. I think your first requirement would point you to either INFORMIX, Unify or Ingres, and perhaps Oracle, depending on what you mean by "large enough share". I don't know much about Unify, but the other three pre-process 3GL programs. Informix has what I consider the only true 4GL in the relational world. Both Ingres and Oracle market 4GL's, but as far as I'm concerned, neither of them are robust enough to warrant calling them true languages, let alone 4GL's. Anyway, I wish you luck. When you get right down to it
monty@delphi.uchicago.edu (Monty Mullig) (05/14/89)
>>I am trying to select a commercial RDBMS product to be used as a back-end >>for a system we're working on. Here are a few criteria for selection: >> >> * RDBMS should have a large enough share of the Unix(tm) RDBMS market; >> * RDBMS should have a quality (stable, well designed, working, complete) >> programmatic (3GL) interface (no pre-processors, such as ESQL, required); .. >No offense, but that seems to be a pretty arbitrary requirement to >place >second on a list ordered roughly by importance. Just as an example, you >are technically ruling out any C based system, since C pre-processes >macros by default. A stiff requirement indeed for a UNIX based system. this is true, although i think that the request (correct me if i'm wrong) is for a 4GL that works directly with the dbms *and* provides the power of sequential processing, a miserably weak area of SQL based database engines unless you use ESQL. but ESQL/C or whatever is no 4GL, and the "4GL" in Ingres (just an example) fall way, way short of expectaions. you pretty much have to use ESQL for true procedural programming. so, doom and gloom ? maybe not. i hear that FOCUS is a great 4GL, but i've never used it. everyone i know who has, though, has been disgustingly pleased. FOCUS is actually a 4GL, not a dbms, but it can read data from just about any kind of file (even CCA's M204). i'd give FOCUS a real close look. if you get trapped in the SQL scene like we did, give sybase a look for power transaction processing. --monty univ of chicago
egn@laidbak.UUCP (E. G. Nadhan) (05/15/89)
In article <3199@tank.uchicago.edu> cs_bob@gsbacd.uchicago.edu writes: >I don't know much about Unify, >but the other three pre-process 3GL programs. Unify pre-processed 3GL programs too like the other three -- INGRES, ORACLE and INFORMIX. E.G.Nadhan {amdahl|att|cbosgd|spl1|sun|uwmcsd1|yclept|nucsrl} !laidbak!egn
allbery@ncoast.ORG (Brandon S. Allbery) (05/20/89)
As quoted from <2335@laidbak.UUCP> by egn@laidbak.UUCP (E. G. Nadhan): +--------------- | In article <3199@tank.uchicago.edu> cs_bob@gsbacd.uchicago.edu writes: | >I don't know much about Unify, | >but the other three pre-process 3GL programs. | | Unify pre-processed 3GL programs too like the other three -- | INGRES, ORACLE and INFORMIX. +--------------- Only if you use Unify's ESQL product, which didn't exist before Unify 3.2. *All* versions of Unify (well, "old" Unify; don't know about Unify 2000) have direct HLI functions callable from C. !!!NOTE!!! Unify HLI functions are NOT SQL-related! The "upp" preprocessor is just the standard Reiser cpp with flexnames in order to deal with long COMB key components, and using '$' as the trigger to avoid confusing the real cpp. On systems with flexnames compilers, I've patched SCOM to output '#' instead of '$' and used the standard cpp with no problems. Oh, and one other thing: Oracle has a direct HLI interface as well. You code SQL statements in C strings and call Oracle functions to attach input and output bindings and open cursors, etc. From what I've seen of it, it's easier to use the "pcc" preprocessor and embedded SQL. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
rk@unify.UUCP (Ron Kuris) (05/25/89)
In article <13661@ncoast.ORG> allberry@ncoast.ORG (Brandon S. Allberry) writes: > As quoted from <2335@laidbak.UUCP> by egn@laidbak.UUCP (E. G. Nadhan): > +--------------- > | In article <3199@tank.uchicago.edu> cs_bob@gsbacd.uchicago.edu writes: > | >I don't know much about Unify, > | >but the other three pre-process 3GL programs. > | > | Unify pre-processed 3GL programs too like the other three -- > | INGRES, ORACLE and INFORMIX. > +--------------- > > Only if you use Unify's ESQL product, which didn't exist before Unify 3.2. > *All* versions of Unify (well, "old" Unify; don't know about Unify 2000) > have direct HLI functions callable from C. !!!NOTE!!! Unify HLI functions > are NOT SQL-related! With UNIFY 2000, a new set of RHLI calls are available. These calls are access method independent. Of course, there are compatability archives for HLI users available as well. I may be mistaken, but I believe preprocessing of UNIFY 2000 programs is only necessary if you want to do compile time name binding, rather than runtime name binding. A new ucc is still provided, which does all the "preprocessing" almost transparently anyways. In summary, even Unify 2000 has RHLI functions callable from C. I may be slightly wrong here because I'm primarily working with 4.0/1.4 and later releases of this product here at Unify. If you want to know for sure, send email and I'll route it to a U2000 authority :-). -- Ron Kuris (916) 920-9092 rk@unify.UUCP {{ucdavis,csun,lll-crg}!csusac,pyramid,sequent}!unify!rk