ajayshah@castor.usc.edu (Ajay Shah) (09/11/89)
One of the aspects of the Unify DBMS which really appealed to me was
his low-level care about referential integrity. I don't know much
about other DBMS'; is this a common idea? (or do they let you build
tables any which way).
Are there non-flatfile DBMS' on the PS/PS2 platform which guarantee
referential integrity on the scale that Unify does (i believe Unify
has given up in the PC market after version 3.2).
--
_______________________________________________________________________________
Ajay Shah, (213)747-9991, ajayshah@nunki.usc.edu
Gandalf for President!
_______________________________________________________________________________negris@southbay.sybase.com (Tim Negris) (09/12/89)
SQL Server from Sybase will do what you want. It's available on OS/2 platforms and it provides for complete database integrity. Sybase allows you to define Primary and Foreign Key and create Triggers for data modification operations. Triggers are stored procedures which are automatically executed by the database when some predefined event occurs. When you attempt to UPDATE, INSERT, or DELETE the database will automatically execute the appropriate trigger. In addition to referential integrity Sybase also provides for other kinds of database integrity: Entity Integrity (of course) - Primary keys must contain unique, non-null values. Domain Integrity - A column value must be of a given type, belong to a given set of values, and have a given format. User-defined Integrity - Sybase allows you to write explicit rules that must be obeyed by the data and programs. In conjunction with triggers and other stored procedures, plus user-defined data types, you can make accommodate arbitrary events and state changes not accounted for with referential integrity. Very few other databases that I'm aware of provide this level of integrity.
bsa@telotech.UUCP (Brandon S. Allbery) (09/13/89)
In article <5030@merlin.usc.edu>, ajayshah@castor (Ajay Shah) writes: +--------------- | Are there non-flatfile DBMS' on the PS/PS2 platform which guarantee | referential integrity on the scale that Unify does (i believe Unify | has given up in the PC market after version 3.2). +--------------- Unify Corp. didn't give up on the PC market, it gave up on the old ENTER/SSQL UI, which was (frankly) crap. Unfortunately, the Accell UI is too big to run under DOS. As for your question: in older RDBMSes, the only one that provided real relational integrity was Sybase. I believe all of the SQL-based RDBMSes are adding referential integrity now; and Unify has, with Unify 2000, brought its relational integrity into line with the evolving standard. (Unify's relational integrity was fine, but you couldn't automatically cascade a record (row) deletion to its children.) ++Brandon -- -=> Brandon S. Allbery @ telotech, inc. (I do not speak for telotech.) <=- Any comp.sources.misc postings sent to this address will be DISCARDED -- use allbery@uunet.UU.NET instead. My boss doesn't pay me to moderate newsgroups. ** allbery@NCoast.ORG ** uunet!hal.cwru.edu!ncoast!{allbery,telotech!bsa} **
bg0l+@andrew.cmu.edu (Bruce E. Golightly) (09/14/89)
At a meeting of the Western PA Ingres Users Association yesterday, we got a brief preview of version 7.0. Among other things, Ingres 7.0 will include rules, which are stored procedures executed in the manner of triggers on UPDATE, INSERT or DELETE. The description we got sounded really slick. Projected ship date is sometime this quarter.
supp@tank.uchicago.edu (Steve Upp) (09/14/89)
In article <sZ3crv600WB5E6Dmdp@andrew.cmu.edu> bg0l+@andrew.cmu.edu (Bruce E. Golightly) writes: >At a meeting of the Western PA Ingres Users Association yesterday, we got >a brief preview of version 7.0. Among other things, Ingres 7.0 will include >rules, which are stored procedures executed in the manner of triggers on >UPDATE, INSERT or DELETE. The description we got sounded really slick. >Projected ship date is sometime this quarter. This is particularly scarry to me. I've been using Ingres 6.2 (VMS 5.0) this summer to write up a straightforward database system for a department here at the University of Chicago and have found Ingres an occassionally frustrating system to work with. I can (but won't now, unless many people would like to see it) show you a select statement in 4GL of ~15 lines (I don't remember off hand) that is guaranteed to completely crash Ingres 6.2's back end. I mean completely crash it - as in dead, gone, outa here! You'll have to run ii_startup.com to get it back up again. In our pursuit of a solution to this problem it comes out that RTI had a bug report on this problem that goes back to version 6.0 (a year ago)! They just never got around to fixing it. I went to a local users group meeting to bring up this topic for discussion and was amazed at how nonchalantly most people took this. If the backend crashes who knows what state your data will be left in! That should matter if you are running in a production environment (like we will be here). Luckily, I was the only person using 6.2 on this machine at the time. AS A SIDE NOTE: If you have the disk space (and not everyone does) it is a very good idea to run two copies of Ingres 6.2 at the same time. One for development only and the other for production systems otherwise you may find yourself in a heap of trouble like the above describes. My complaint is that RTI SHOULD NOT come out with yet another "really great" version of system enhancements when their system has reported bugs that aren't getting fixed. To me, stability is the key to any companies success not just bells and whistles. I'm sure RTI people on the net are going to scream loudly about this! They do seem to defend their product strongly. And I'm sorry if I'm putting RTI on the spot here, but this kind of thing really does irk me. The response I got from a 'salesman' at RTI was that these problems are all being handled with sufficient effort and that the new bells and whistles are added by a seperate group of people. In my view some of those people should be moved over to the bug fixing group before version 7.0 is released. I know that on any new piece of software that has been rewritten like Ingres 6.0 has, there will be problems, that is one thing. But to continue to produce bell and whistle versions while not fixing major problems like this one quickly RTI runs the risk of alienating their user community. I am not our site's Ingres administrator, I don't deal directly with RTI nor do I speak for the University of Chicago. I'm just a summer employee who wrote a program with an RTI product. I'm only giving you my own personal reactions to RTI's plans of a version 7.0 and I couldn't believe it when I heard it! On the positive side, the system I have written does work. I like the features of 6.2 over our previous 5.?? version I just wish RTI would get its act together on bug fixes.... Also I'm not certain of the current status of that bug, I just coded around it and went on.... ---- Steve Upp InterNet: supp@tank.uchicago.edu University of Chicago University Computing Organizations
gupta@cullsj.UUCP (Yogesh Gupta) (09/14/89)
In article <1989Sep12.224332.585@telotech.uucp>, bsa@telotech.UUCP (Brandon S. Allbery) writes: < In article <5030@merlin.usc.edu>, ajayshah@castor (Ajay Shah) writes: < +--------------- < | Are there non-flatfile DBMS' on the PS/PS2 platform which guarantee < | referential integrity on the scale that Unify does (i believe Unify < | has given up in the PC market after version 3.2). < +--------------- < < [...] < As for your question: in older RDBMSes, the only one that provided real < relational integrity was Sybase. < [...] < ++Brandon < -- I do not know how you define "older RDBMSes", but CA-DB (formerly known as IDMS/SQL as well as Enterprise:DB from Cullinet) has supported referential integrity since its *first*release*. CA-DB is in release 1.4 on the VAX and is about to be released in Beta on the PC. -- Yogesh Gupta. | The opinions expressed in this article Computer Associates. | are those of the author and do not | represent those of Computer Associates.
robf@squid.rtech.com (Robert Fair) (09/14/89)
>From: supp@tank.uchicago.edu (Steve Upp) writes on a number of topics (most of which it is not appropriate for me to coment on, especially bugs not getting fixed), and also mentions: >If the backend crashes who knows what state your data will be left in! This should normally be no problem in INGRES release 6 - all logging and recovery is done through a independent subsystem (DMFRCP & DMFACP) which is still running if a DBMS server goes down. These will rollback any non-committed transactions, or rollforward any transactions which have been committed but not yet updated to the database. (e.g. with Fast Commit), so your data should remain in a consistent state. All the transaction info is stored in a logfile (often a raw device on UNIX) so that in the event of a machine crash the recovery process will automatically rollback/redo any transactions when it comes back up later. About the only way data can get lost is if the logfile is manually removed - and if you go manually removing files from a DBMS all bets are off anyway... On rules in 7.0, they really do work very nicely, especially with cascading/recursive style updates - I just wish they could have been discussed a few weeks ago in the referential integrity thread, but we try not to discuss new features on the net before they are available. (Rules is just one of many equally significant features in 7.0 - look out for announcements in the near future) Robert L. Fair Technical Support Relational Technology, Inc
speyer@joy.cad.mcc.com (Bruce Speyer) (09/14/89)
In article <1989Sep12.224332.585@telotech.uucp> bsa@telotech.UUCP (Brandon S. Allbery) writes: >... >As for your question: in older RDBMSes, the only one that provided real >relational integrity was Sybase. I believe all of the SQL-based RDBMSes are >adding referential integrity now; and Unify has, with Unify 2000, brought its >relational integrity into line with the evolving standard. (Unify's >relational integrity was fine, but you couldn't automatically cascade a record >(row) deletion to its children.) I was using Interbase's referential integrity capability over 3 years ago. Bruce Speyer / MCC CAD Program WORK: [512] 338-3668 3500 W. Balcones Center Dr., Austin, TX. 78759 ARPA: speyer@mcc.com
monty@delphi.uchicago.edu (Monty Mullig) (09/14/89)
i can't believe that rti would announce yet another release of their product while their current product has known backend stability problems. in fact, we're too frightened of 6.x backend horror stories from the VMS sites here on campus to upgrade from 5.0 on our Unix machines. i really dislike what seems to me to be a habit of RTI's of announcing new products with wildly optimistic delivery dates (this quarter for 7.0 ??!!), delivering very late, buggy products, and then immediately announcing new versions before the current bugs are fixed. sorry if this posting offends anyone at rti, but you've got to realize how unbelievable it sounds to us that you'd already be announcing a new release of your product. --monty
deal@kodak.UUCP (Stephen M. Deal) (09/15/89)
In article <3632@rtech.rtech.com> robf@squid.UUCP (Robert Fair) writes: > >>From: supp@tank.uchicago.edu (Steve Upp) >>If the backend crashes who knows what state your data will be left in! > >This should normally be no problem in INGRES release 6 - all logging >and recovery is done through a independent subsystem (DMFRCP & DMFACP) Valid point Rob, recovery is much better with the new architecture. However you failed to address the concerns of the users. Adding features is fine as long as there is a stable foundation upon which to build applications. I am aware of "bugs" or "weaknesses" in the Ingres 6.2 query optimizer which cause it to choke and die on complex queries involving subselects. Perhaps the queries could be rewritten with more joins but SQL remains the *standard* with which we all must share the burden and it permits subselects. An idealistic vendor responds instantly to their customers with fixes first, workarounds second and then excuses. Show the technical community that your company is of the first calibur and is interested in support and service after the sale. *I* (personally) prefer your products and company because of your stance toward open architectures (not the "Put my product everywhere" approach) and robust toolset. But then I am easily won over by sexy technical sophistication rather than aggressive blitzkrieg marketing :-) Steve Deal UUCP: ...rutgers!rochester!kodak!eis!deal Internet: deal@eis.Kodak.COM Disclaimer: "Everyone is entitled to an opinion, the above is ABSOLUTELY mine and not that of my employer."
bg0l+@andrew.cmu.edu (Bruce E. Golightly) (09/15/89)
I feel I have to comment on Ingres bug fixes. A previous post made it sound like RTI doesn't fix bugs or provide work-arounds, but only makes excuses. This is not the case in our experience. I must admit that we have had bad experiences a couple of times. In tracing these back, though, the source of the problem in getting good tech support was not simply in RTI, but a combination of factors, including our own staff. Beyond that, Ingres is still my product of choice. When there have been bugs, we usually get a work-around quickly, sometimes during the initial trouble report call. In most cases, a patch tape is forth-coming within a week or so. (There have been a couple that went longer, though.) Maybe some of the support issues are OS related? We run most of our production systems on DEC VAX/VMS machines. I cannot speak for the Unix world. Bruce ------------------------------------------------------------------------------ Disclaimer: If I or any of my co-workers are caught, our bosses will disavow any knowledge of our activites. This message will self-destruct in 15 seconds. I would suggest that you move back from the terminal.
UH2@PSUVM.BITNET (Lee Sailer) (09/16/89)
I'm not sure what level of Referential Integrity Unify guarantees, but
I do know that Rbase does. You can specify a rule such as
ManagerID not NULL and ManagerID = EmployeeID in Employee
(tho' the syntax is a little different) which will reject any record
with a null ManagerID or for whom the ManagerID is not a valid employee.
The main problem with RBase is that all it does at that point is barf.
There is no BEGIN TRANSACTION-END-COMMIT-ABORT capability built in.
You have to fake it by creating your own local tables, and only integrating
them into the real tables after all has checked out.
leeelgie@canisius.UUCP (Bill Elgie) (09/17/89)
In article <UZ4DDwa00WB4E2P2JY@andrew.cmu.edu>, bg0l+@andrew.cmu.edu (Bruce E. Golightly) writes: > I feel I have to comment on Ingres bug fixes. A previous post made it sound > like RTI doesn't fix bugs or provide work-arounds, but only makes excuses. > This is not the case in our experience. > We started with version 2 on VMS and are now on version 5.somethingorother on ULTRIX and MIPS RISCos. Throughout, we have found INGRES to be stable and certainly not "buggy". We have encountered some bugs over the years, but I would say that, especially given the complexity of the system, INGRES has been "cleaner" than most of the commercial software we have used. > > Beyond that, Ingres is still my product of choice. When there have been bugs, > we usually get a work-around quickly, sometimes during the initial trouble > report call. In most cases, a patch tape is forth-coming within a week or > so. (There have been a couple that went longer, though.) > We have never been told that "yes, we know about the bug and it will be fixed in the next release". INGRES tech people have been willing to log in to trace down problems we have encountered. Also, INGRES has never hassled us about "bugs" that they traced down to our own programming errors. greg pavlov (under borrowed account), fstrf, amherst, ny
cpcahil@virtech.UUCP (Conor P. Cahill) (09/17/89)
In article <89259.111659UH2@PSUVM.BITNET>, UH2@PSUVM.BITNET (Lee Sailer) writes: > I'm not sure what level of Referential Integrity Unify guarantees, but > I do know that Rbase does. You can specify a rule such as > > ManagerID not NULL and ManagerID = EmployeeID in Employee You can specify the same thing in unify. > (tho' the syntax is a little different) which will reject any record > with a null ManagerID or for whom the ManagerID is not a valid employee. Again, same with unify. > The main problem with RBase is that all it does at that point is barf. > There is no BEGIN TRANSACTION-END-COMMIT-ABORT capability built in. > You have to fake it by creating your own local tables, and only integrating > them into the real tables after all has checked out. This is similar to the way unify behaved in versions 3.2 and 4.0, but with unify 2000 you have the full begin, commit and/or abort transaction capability. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+