ykchan@elecvax.eecs.unsw.oz (Yk Chan) (05/03/89)
I am starting a database project on unix. I have access to an Ingres and also Sybase. Anyone out there in the net has comment on the pro's and con's of Ingres vs Sybase. Price is not an issue because I have access to both already. A third choice will not be considered because of the same reason. Thanks in advance. y.k.chan School of EE and Comp. Sic. UNSW. 697-4048 ykchan:elecvax:oz
elgie@canisius.UUCP (Bill Elgie) (05/07/89)
In article <4306@elecvax.eecs.unsw.oz>, ykchan@elecvax.eecs.unsw.oz (Yk Chan) writes: > I am starting a database project on unix. I have access to Ingres and Sybase. > Anyone out there in the net has comment > on the pro's and con's of Ingres vs Sybase. > Price is not an issue because I have access to both already. You are in an ideal situation: you have access to your range of choices. If the application is important, the absolutely best thing that you can do is to design and implement a subset of it under both dbms packages. Throw in a few kinks (like several really large tables) to push the two. This should give you much more relevant information than reams of anecdotal info from people whose applications, end-user demands, and working style may bear no relationship to your's. greg pavlov (under borrowed login), fstrf, amherst, ny
jordan@cs.columbia.edu (Jordan Hayes) (05/08/89)
Yk Chan <ykchan@elecvax.eecs.unsw.oz> asks: I am starting a database project on unix. Ok, I'll bite. I will assume the following: a) you're a student (university of new south wales?) b) by "project" you don't mean "product" c) you're going to want to do a lot of programming, a lot of design, and a bunch of debugging d) you may not care much about performance issues e) you're looking to learn a bit through this process I.e., you're not like most of the people who post regularly on this newsgroup who are concerned with what to buy, why to buy, how fast is it, and is it state of the art. So, you'll have a much easier time. I think both Sybase and Ingres will suit your needs just fine. They both are relational databases using SQL (more or less), and they both have a way of providing a programming interface to the database. Your choice will come down to an easy, philosophical question: do you like the way C works, or do you like the idea of an imbeded pre-processed "language" for your development? Sybase's DB-Library looks like C, and Ingres' EQUEL is an embedded language that you pre-process. With Sybase, you know where you stand. It's neither harder nor easier to program in DB-Library than it is in C. For Ingres, sometimes embedded languages make things harder, if you want to do a lot of mixing of database stuff with Unix; sometimes it makes it easier to prototype and debug. Strictly religion. /jordan
deal@kodak.UUCP (Stephen M. Deal) (05/08/89)
In article <2350@canisius.UUCP> Greg Pavlov (alias Bill Elgie) writes: >In article <4306@elecvax.eecs.unsw.oz>, ykchan@elecvax.eecs.unsw.oz (Yk Chan) writes: >> I am starting a database project on unix. >> I have access to Ingres and Sybase. >> Anyone out there in the net has comment >> on the pro's and con's of Ingres vs Sybase. > > You are in an ideal situation: you have access to your range of choices. > If the application is important, the absolutely best thing that you can do > is to design and implement a subset of it under both dbms packages. Throw in > a few kinks (like several really large tables) to push the two. I guess if performance is critical to your application then you should benchmark the performance of each. Just make sure that you compare apples to apples. On the other hand application development tools may be important because you want to do quick prototypes and minimize the amount of esql and C. If so then you may want to look at the capabilities that the Application Tools (I dislike the term 4GL) each of the DBMS vendors provides. Using the approach that Greg mentioned, implement a small subset of the application(s) that you plan to build and see what kind of work it takes. Even if you do this without the Application Tools using ANSI SQL and ANSI C you will learn a great deal. about the underlying DBMS. -- Steve Deal UUCP: ..rutgers!rochester!kodak!deal Disclaimer: "Everyone is entitled to their own opinion, the above is mine and not that of my employer."
christie@kylie.oz (Chris Tham) (05/10/89)
In article <4306@elecvax.eecs.unsw.oz> ykchan@elecvax.eecs.unsw.oz (Yk Chan) writes: >Anyone out there in the net has comment on >the pro's and con's of Ingres vs Sybase. It depends. We found Ingres 5.0 to be reliable if a bit slow. Program development using OSQ/ESQL quite painless especially if you also use the forms package and so on. Ingres does not understand make, however, and for program development you need to use its own program maintenance tool called abf or something (its been a while...) although you can usually kludge up Ingres and make by analysing exactly how abf works and then duplicating the programs it calls in your Makefile. All in all, a comfortable environment to work in if you are used to building database applications in non-Unix machines, but very uncomfortable for seasoned Unix programmers as all the usual Unix tools such as SCCS/RCS, make, grep, etc. etc. are unavailable. Also, when programming in ESQL/EQUEL, we found EQUEL to be more powerful than ESQL and I ended up doing all embedded stuff in QUEL rather than SQL. The easiest way to do Ingres programming is to use all its tools, especially OSQ which is its programming language based on SQL/QUEL. Sybase on the other hand is very fast, but only supports SQL. It has a very good SQL language, full of very very useful extensions such as control flow, block structuring procedural based language with user defined datatypes. Other interesting things are stored procedures that are wholly contained in the SQL database server and are user callable, triggers that operate whenever a certain database operation is being performed, etc. etc. These extensions are very useful but completely nonportable so be careful about using them if you would like to port your application to another database system later on. Sybase tools are not as complete or as easy to use as Ingres making application development more difficult (the screen or forms system is not very usable on non bitmapped terminals as it is very mouse orientated). The easiest way to do Sybase development is to decide what your database structure is going to be, then build all the necessary tables, triggers that you might find useful, stored procedures for common database operations on your tables, and then finally write your application in C with appropriate calls to execute stored procedures in the dataserver. The C interface is crude but workable, you view the dataserver as a sort of I/O channel that you have to open, close and maintain. You send SQL to the dataserver as ASCII text after sprintf() like formatting, you receive execution results and data by quering the dataserver status and 'binding' columns in a row that is being returned into areas of memory. You can use all Unix program development tools as developing in Sybase is just like writing a C program. Summary: use Ingres if you want something in a hurry and don't mind sacrificing performance and can live with its development tools. Use Sybase for speed, if you cannot live without its extensions and also if you have a Sun or use your own screen/forms package. -- Internet: christie@kylie.otr.oz "I'm Pink, therefore I'm Spam" JANET: christie%kylie.oz@uk.cc.ucl.cs Phone: +612 235-0255 UUCP: {uunet,hplabs,mcvax,ukc,nttlab}!munnari!christie@kylie.otr.oz Mail: Optech Research Pty Ltd, Level 60 MLC Centre Sydney NSW 2000 AUSTRALIA
c162-aj@zooey.Berkeley.EDU (Mark Christiansen) (05/13/89)
A magazine/newspaper called Computerworld has many very good articles comparing and describibg various databases. As for some recent light research that I have done on Sybase, they are (as of the articles read from 1988) the only database with government security clearance, data integrity (ie. non null primary keys, and matching foreign keys, etc), and they have an excellent data backup. The DB may be proted from one VAX on a network to another if the original 'goes down' and the DB also uses a mirror disk access system where it saves to different places on the disk, or different drives simultaneously to protect lose of data to disk crashes (or limits the lose at least). DataServer (the DBMS for Sybase) also using a multi-threaded access to relations so that many users may be using the exact same info without integrity conflict (ie. one writer, but many readers) and DataServer also can shovel many users into a small area. Somewhere on the order of 50 users to 1 Meg (don't have the articles in front of me) which leaves massive room for caching resulting in less I/O. This is all in addition to the fact that Sybase is an amazing start-up company, only 5 1/2 years old with product for only 3 1/2, and also their remarkable DataTools that use bitmapped or character terminals automatically from the same server. Any other info or corrections to this enthusiastic but not too researched posting is welcome. Mark
jkrueger@daitc.daitc.mil (Jonathan Krueger) (05/13/89)
In article <13680@pasteur.Berkeley.EDU>, c162-aj@zooey (Mark Christiansen) writes: >[According to Computerworld, Syabase] is >(as of the articles read from 1988) the only database with >government security clearance, Not true. What you mean is certification of secure system operation, and no DBMS has this; none has been certified secure at any level. Sybase has said they are aiming at getting one of their products certified at, I believe, the B1 level. This means they will put resources into it and they hope to get it. It doesn't mean they have gotten it. No one has. >data integrity (ie. non null primary >keys, and matching foreign keys, etc), Not true. Unify has this, probably others as well. But no matter. This is Computerworld's usual standard of accuracy and integrity. If you need the facts, don't expect them to do your homework for you. -- Jon --
allbery@ncoast.ORG (Brandon S. Allbery) (05/19/89)
As quoted from <587@kylie.oz> by christie@kylie.oz (Chris Tham): +--------------- | your application to another database system later on. Sybase tools are | not as complete or as easy to use as Ingres making application | development more difficult (the screen or forms system is not very | usable on non bitmapped terminals as it is very mouse orientated). +--------------- According to the latest Unix/World, Accell/SQL is available as a front-end for Sybase on non-bitmapped terminals. THAT should be one k*ck-*ss combination! Oh -- on a slightly different tack, I was amused to note that there are *three* front-ends available for Oracle aside from Oracle's own: Accell/SQL, For-Ten (who?) and Progress (well, it's "in development"). Quite a damning statement about SQL*Forms, if you ask me.... (There were four available for Sybase, but that's because Sybase's native forms package is bitmapped; all of these were character-oriented.) ++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
ben@calvin.sybase.com (ben ullrich) (05/20/89)
In article <13656@ncoast.ORG> allbery@ncoast.UUCP (Brandon S. Allbery) writes: > >Oh -- on a slightly different tack, I was amused to note that there are >*three* front-ends available for Oracle aside from Oracle's own: >Accell/SQL, For-Ten (who?) and Progress (well, it's "in development"). >Quite a damning statement about SQL*Forms, if you ask me.... (There were >four available for Sybase, but that's because Sybase's native forms package >is bitmapped; all of these were character-oriented.) Just a minor clarification: Sybase's ``native forms package'' is terminal independent: the low-level routines worry about what terminal you're on; most any front-end application you might build with our forms packages will run on both types of terminals with no modifications as long as both terminals are supported. The front ends run principally on *character* terminals, and on bit-mapped workstation terminals if such an interface is generally available with the machine. Thus, Sybase supports character-based front ends on, for example, Pyramid, with no bitmapped terminal support, because Pyramid doesn't make bitmapped terminals for its computers. Similarly, Sun bitmaps and VAX Station bitmaps are supported, since these are often standard equipment on a Sun or VAX Station. ..ben ---- ben ullrich consider my words disclaimed,if you consider them at all sybase, inc., emeryville, ca +1 (415) 596 - 3500 "skinheads are pinheads!" -- greg sullivan ben@sybase.com {pyramid,pacbell,sun,lll-tis}!sybase!ben
eric@pyramid.pyramid.com (Eric Bergan) (05/20/89)
In article <4320@sybase.sybase.com> ben@calvin.sybase.com (ben ullrich) writes: >In article <13656@ncoast.ORG> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >> >>(There were >>four available for Sybase, but that's because Sybase's native forms package >>is bitmapped; all of these were character-oriented.) > >Just a minor clarification: Sybase's ``native forms package'' is terminal >independent: > Thus, Sybase supports >character-based front ends on, for example, Pyramid, with no bitmapped >terminal support, because Pyramid doesn't make bitmapped terminals for >its computers. Just one more minor clarification: Pyramid now sells a bitmapped X terminal, and will be supporting X based frontends just as fast as the various vendors convert their applications to X. ( I know, this borders on a commercial, but just wanted to set the record straight.) ...!pyramid!eric -- eric ...!pyramid!eric
jkrueger@daitc.daitc.mil (Jonathan Krueger) (05/22/89)
In article <70862@pyramid.pyramid.com>, eric@pyramid (Eric Bergan) writes: > Pyramid now sells a bitmapped X terminal, and will be supporting >X based frontends just as fast as the various vendors convert their >applications to X. > > ( I know, this borders on a commercial, but just wanted to >set the record straight.) No problem Eric, I'm glad you mentioned it. I no more want to buy a separate window system for each vendor's DBMS than I'd care to buy a different terminal for each text editor. Which in the bad old days we did, by the way. X is available as a specific solution for this problem, among others. Which DBMS vendors are supporting X clients or planning to? The only one I'm aware of is RTI. How about Sybase, Oracle, Informix, others? What clients, what functionality, what user interface? Based on what toolkits, if any? Will toolkit access be provided to developers? Tested on which hosts' Xlibs? Eats how much memory on an X terminal? Shipping when? If any vendors care to respond, and provide at least specific answers to these questions, they will satisfy the relevant section of Gene Spafford's Rules for Posting to Usenet: ]Announcement of professional products or services on Usenet is allowed; ]however, since someone else is paying the phone bills for this, it is ]important that it be of overall benefit to Usenet . . . ]Advertising hype is especially frowned upon -- stick to technical ]facts. So within those limits, we'd love to hear from you, and this seems an appropriate place and time. -- Jon -- --
elgie@canisius.UUCP (Bill Elgie) (05/22/89)
In article <13656@ncoast.ORG>, allbery@ncoast.ORG (Brandon S. Allbery) writes: > Oh -- on a slightly different tack, I was amused to note that there are > *three* front-ends available for Oracle aside from Oracle's own: > Accell/SQL, For-Ten (who?) and Progress (well, it's "in development"). > Quite a damning statement about SQL*Forms, if you ask me.... Well, I never thought much of SQL*Forms. But I think that what we are seeing - front ends tacked on to other vendors' dbms's - will become increasingly widespread. My guess is that Oracle is being targeted early on mainly because of its large installed base. greg pavlov (under borrowed account), fstrf, amherst, ny
dwayne@fungus.bsd.uchicago.edu (Dwayne H. Spradlin) (12/22/89)
I requested a while ago that people "in the know" would relay to me a comparison of Ingres and Sybase. Well the only responses I got were for me to post the results. Anyway, I just wanted everyone that mailed to me asking for results summaries to know that I didn't blow you off, it's just that no-one seems to know the answer. Maybe because Sybase is a relatively new product. Anyway I didn't ignore everybody. By the way If I EVER get an answer to my question I will still post my the answer. Dwayne Spradlin C C Dw
Mats.Sundvall@bio.embnet.se (Mats Sundvall) (01/10/90)
Our INGRES salesman tried to persuade us to buy INGRES instead of SYBASE referring to the object oriented capabilities with possibilities to define new classes and to do operator overloading. He also talked about some sort of knowledge shell. I now wonder if the same capabilities will come in the near future in Sybase. Can anyone comment on differences between Sybase and Ingres concerning multi-server databases. Mats Sundvall, Biomedical Center University of Uppsala Sweden