Re: Oracle vs Informix comparison

Rajashekar Sundaramurthy wrote: > > In <32AAC5F9.34D2@mindspring.com> Tim Schaefer > <tschaefe@mindspring.com> writes: > > > >Billy Wheeler wrote: > > > >> This is *very* interesting - you as a developer don't have to code > the > >> sp's/triggers? How do you specify what must get replicated and where > >> to? What happens if you add new servers which must also be updated? > >> > >> For once, I'm not just being difficult, just interested to see how > >> you guys do it. > >> -- > >> Ciao, > >> > >> Billy > >> > >> I'd be in favour of apathy, but I just couldn't be bothered... > >Billy, > > > >As an aside to this thread, and not trying to advertise a product, you > >may want to study Praxis' Replication software. > > My understanding is that Praxis' Replication software is required if > you want to replicate across heterogenous environments (Informix to > Oracle or SQLServer).For Informix to Informix replication, you just > need ER from Informix. > > Can someone throw more light on this...? > > Raj Raj, Since I'm the one that mentioned Praxis, I can say that the original thread describing the Oracle replication sequence is pretty much the way Praxis works. A trigger and stored procedure combo are the same basically as described by the Oracle sequence. I haven't even begun to study the basic Informix replication, basically because the whole issue of replication is science enough for a whole separate career--and product line. Others are out there besides Praxis, however Praxis appears to have done some serious thought with regard to their product. One other interesting element is SQLServer, a very stored-procedure dependent product that I'm working on with Informix. If you have spent most of your time with Informix, and not SQLServer, you should take a look at this product at least from the interface. Sure, I'm pro-Informix, but to make the point, stored procedures drive the SQLServer product. From a data architect stand-point SQLServer allows a lot of cool design cultivation, but this has to be experienced to be understood. I hope the WGS interface moves into the sophistication that SQLServers' interface enjoys. Haven't seen the Oracle product--the Borg haven't been my way... :-) The whole replication scenario really needs to be understood that replication is something that can be handled through either a sophisticated or non-sophisticated approach. To depend on db software solely for replication is to misunderstand the real issue. The real issue is about scalabilty. For small shops and peer-to-peer replication you will have a simple scenario where the base, or core replication components of the db software can meet the need. But to size replication across an enterprise where a master data base cascades out to several other sites--could be in the hundreds or thousands of servers--the complexity and timing are beyond simple core-product-descriptions and comparisons. A data distribution scheme is something that turns into a full-time job--not unlike a DBA. This could become a whole career path like DBA, a "Minister of Replication". :-) the data base vendor may not be able to offer a sophisticated-enough product to meet the need from their own software. At the complex end of replication timing becomes a science because of the scale, at the simple end it looks like a simple copy operation. Replication is not just copying data bases, it's the science of distributed data bases staying in sync. Maybe the term replication should not even be used, but rather distribution. "Replication", as Mark Sigler of Informix once told me, "is not trivial", and boy he wasn't kidding... :-) -- Tim Schaefer \\\\|// tschaefe@mindspring.com (6 6) ------------------------oOOo---( )---o00o--------- Liberty: http://www.lp.org Informix: http://www.iiug.org --------------------------------------------------