Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!kodak!deal From: deal@kodak.UUCP (Stephen M. Deal) Newsgroups: comp.databases Subject: Re: Referential Integrity in commercial DBMS's? Message-ID: <2103@kodak.UUCP> Date: 15 Sep 89 01:39:47 GMT References: <5390@tank.uchicago.edu> <3632@rtech.rtech.com> Reply-To: deal@kodak.UUCP (Stephen M. Deal) Organization: Eastman Kodak Co, Rochester, NY Lines: 33 Keywords: INGRES RTI 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."