nigel@hp-ptp.HP.COM (Nigel_Clunes) (09/21/89)
I am involved in a project that will be setting up a 3 to 5
gigabyte database. We are currently looking at using one of
the following.
- Oracle
- Informix
- Sybase
I would like any comments that people wish to make about any
of the above products.monty@delphi.uchicago.edu (Monty Mullig) (09/25/89)
In article <1460001@hp-ptp.HP.COM> nigel@hp-ptp.HP.COM (Nigel_Clunes) writes: >I am involved in a project that will be setting up a 3 to 5 >gigabyte database. We are currently looking at using one of >the following. > > - Oracle > - Informix > - Sybase > >I would like any comments that people wish to make about any >of the above products. we just finished evaluating three products, ingres, sybase, and oracle. we expect our central database to be about one gigabyte. we'll also have a number of smaller databases local to our departments on their servers. we chose sybase. briefly, here is why: our first rule, which went uncompromised: this decision would be based exclusively on products that are currently shipping. announced, to-be-released features were not included in our evaluation. we run on sun servers. for the past year we've used ingres. in the next year the size and complexity (moving from a centralized to distributed database) of our operations would be increasing dramatically. in addition, we needed front ends developed on PCs and backends on unix (or in some cases vms) boxes. early on we posted a query to this group about these three systems (oracle, sybase, and ingres). the responses that we received were extremely negative towards oracle. they were primarily critical of what was perceived to be very poor QA, slow bug fixes (generally promised in the next release), and poor delivery of promised new features. oracle did receive very high rating for its telephone support and it does run on a wide variety of platforms (the largest that we found). but the negative responses were so strongly worded and received at least apparent corroboration from the "don't worry, we do everything you want" attitude of the sales rep [we found that they sometimes redefined what we wanted--like distributed databases--so that it fit what oracle could do, and that they wouldn't tell us that they had changed the definitions unless we forced them to be explicit at all times], that we were frightened off from oracle. that left sybase and ingres. having run ingres (5.0) for a year here and with our business school running it (ingres 6.x) also, we knew ingres well. ingres does allow for frontends to run on PCs and backends on unix or vms boxes. our problems with ingres were: - our business school has had a number of problems with stability of the 6.1 and 6.2 backends. only 6.1 is available on suns now and we were advised to stay on 5.0 at least until 6.2 became available on suns. in addition, PC ingres is only available in 5.0 and there are not even announced upgrade dates to 6.x. to run 6.x backends and 5.0 frontends, we would need a 5.0-to-6.x gateway. unfortunately, one ingres employee told us that he could not guarantee its reliability (he did *not* say, however, that it was UNreliable). to us this meant that the current ingres product for our environment was release 5.0. - ingres (in 5.0 at least) does not support ingres star in the sun environment. thus, no true distributed databases with suns (backends) and ingres. - ingres in 5.0 does not allow outer joins. - pc-ingres is a memory hog and does not support LIM. it does support quarterdeck on 386 machines, but less than 5% of our PC workstations are 386 PCs. - ingres' implementation of the permit for appends has a serious flaw. the statement: create permit insert on table to user where col=value does NOT act as expected. rather than only allowing user to insert rows with col=value, ingres checks table for the existence of a row with col=value and, if it exists, user can insert a row regardless of whether col=value or not. this is not a bug, per se, since ingres does acknowledge this behavior in its documentation. - ingres 5.0 creates a backend for each front-end (single threaded). - ingres' (5.0) version of embedded SQL for 5.0 allows only limited use of c variables and no general string substitution (ie, you cannot generate an embedded SQL statement on the fly in a C program). - ingres' user interface is character based and makes no use of a workstation's bit-mapped graphics or mouse. - ingres' primary development platform is the VAX. this isn's a problem if you have a VAX, but if you have a sun, it means that you product releases (deliveries) will trail the VAX versions by months. - only the DBA can share tables with other users. this can be very inconvenient, especially as the size of the development staff grows larger than a couple of people. the primary strengths of sybase were: - mature, stable multi-threaded backends. this saves memory and helps increase performance by reducing operating system overhead and optimizing query executions. the former can occur in several areas. first, since there is a single backend, the scheduling overhead of the backend process is reduced significantly over single threaded backends. additionally, the reduced memory requirements of a multi threaded backend reduce the likelihood of pages and swaps (fewer memory pages are used). finally, reducing the number of processes with a multi threaded backend reduces the number of context switches that are needed and the likelihood of using up all available hardware contexts. a multi threaded backend can also optimize the execution of multiple queries from many frontends, something that single threaded backends could never do. - stored procedures. precompiled, preoptimized stored procedures provide two big gains, performance improvements and query abstraction. performance gains come from not needing to compile and optimize repetitive queries on each execution. you can also use stored procedures, which allow multiple sql statements, conditional execution (if statements), and up to 256 command line variables, to abstract large or complex queries. stored procedures can be shared with other users and their execution can operate with permissions handled in a method similar to unix's setuid mode. - triggers. events can be scheduled to occur when other events happen in the database. for example, a trigger can be written so that, when a master record is deleted all associated detail records are also deleted. - any user can share a table with another user. - sun is the primary development platform for sybase, which since we use suns, is important. sybase userpp interface tools can also use sun's mouse and bit mapped graphics. - sybase supports distributed databases in the sun environment (or, for that matter any sybase environment) now. the primary advantage that ingres had over sybase, in our environment of suns and PCs, was that ingres had frontend tools for the PCs and sybase didn't. of course, we had already decided to use MS-C and vermont windows to develop our applications, so the abscence of PC tools in sybase didn't mean that much to us. in addition, every review we read or person with whom we spoke who used sybase felt that it was an excellent product that provided what it promised: high performance and robust database serving in a distributed envirnment. we chose sybase. --monty univ of chicago biological sciences division
hans@ditmela.oz (Hans Eriksson) (09/26/89)
In article <5527@tank.uchicago.edu> monty@delphi.UUCP (Monty Mullig) writes: > > the primary strengths of sybase were: I've learnt that Sybase SQL is not the Standard SQL, at least not the mebedded one. How much it differs I do not know, but it was too much difference for us anyway. I would say that this would be a major consideration also. /hans -- Hans Eriksson (hans@ditmela.oz.au) CSIRO/DIT, 55 Barry Street, Carlton, Victoria 3053, Australia (we are GMT+10) Tel: +61 3 347-8644 Fax: +61 3 347-8987 Home: +61 3 534-5188 On a years leave from Swedish Institute of Computer Science (hans@sics.se)
davidm@uunet.UU.NET (David S. Masterson) (09/27/89)
In article <7206@ditmela.oz> hans@ditmela.oz (Hans Eriksson) writes: > I've learnt that Sybase SQL is not the Standard SQL, at least not the > mebedded one. How much it differs I do not know, but it was too much > difference for us anyway. I would say that this would be a major > consideration also. > I'd say the important thing is to get the job done. If you are building your system around one particular database system, you shouldn't be overly concerned with the ANSI Standard (standards were made to be broken and more often than not are!). Too much concern with the standard and you may miss the particular capabilities of a system that will solve your problems really well (for instance, triggers which I don't think are in the ANSI Standard). In my mind, the ANSI Standard does not go nearly far enough in defining what the capabilities of a relational database should be. As such, it is nearly useless as a tool for users to base their expectations on. It is only good in keeping vendors from having wildly varying interfaces and, therefore, help prevent vendor "lock-in". If I remember correctly, Sybase supports a reasonable subset of the standard SQL and "value-adds" to that to put even more of the functionality that belongs in a database server where it belongs (in the database server!). Sybase may have been the first (give or take) to do this as successfully as they have, but I doubt they will be the last (yet another ANSI Standard -- ANSI Standard??). David Masterson uunet!cimshop!davidm p.s. my opinions are my own. I currently have nothing to do with Sybase (much to my regret).