Re: Current Informix vs. Oracle Data

Just to add my 2 cents worth. This is all second hand, word of mouth info so take it "cum grano salis". I was told that Oracle's replication was very slow and somewhat unreliable. Surely they have remedied that by now, however, I marvel at the number of people needed to maintain Oracle databases. I manage several several Informix databases, SE and Online, by myself (and yes, with the grace of God and the help of my friends on the Informix list). It would be great if my division were staffed as well but then I'm not sure what we would do with extra Dbas with nothing to do. I'm also told that Orcale's embedded Web procedures have a downside; it's a bitch to rework them. In terms of database technology, I'd think IBM's Db2 is more of a threat to Informix than the Orca. In terms marketing, the Orca has a distinct lead. I guess you have to ask what you're getting for your dollar. Yours, Nick On Tue, 23 Feb 1999, Peter Ross wrote: > > > Obnoxio The Clown wrote: > > > >From: "Sean Kelsey" <chilliinc@hotmail.com> > > > > >Floodgates are open.... > > > > :-) > > > > [Lots of valid comments made, except the one about Oracle getting > > better... :-] > > > > >-=Eclypse=- wrote in message ... > > >>I'm looking for someone who can give some good input in the Informix > > vs. > > >>Oracle arena. Management is all up on Oracle because "everyone knows > > how > > >>to use Oracle and it's popular and try to find an Informix DBA - there > > >>aren't any, but if you look up Oracle DBAs, they can be found easily." > > > > Two points from personal experience: > > > > 1. Bollocks -- not everyone knows how to use Oracle. You require far > > more training to use Oracle than Informix. Even migrating from Informix > > to Oracle is a pain in the bum. (More on this later) > > In my experience the migration to Oracle of a fairly large application > (1,343,045 lines of 4GL code) and all the database has been fast and > smooth. I used querix for this migration. > > > > > > > > 2. You can find more Oracle DBAs because Oracle needs more DBAs. You can > > administer IDS far more easily than Oracle. And just because they see > > thousands of job ads for Oracle DBAs, doesn't mean they're out there. I > > used to run a personnel agency, and it was just as difficult or more > > difficult for us find Oracle DBAs. And Oracle people are more expensive. > > > > In Oracle's favour, and in management's defence, Oracle _*really*_ know > > how to market to management. I would say they don't even bother to > > market to techies. They make it far easier to sell Oracle than Informix. > > > > >>I really can't compare the two because I have never seen Oracle, never > > >>used Oracle, and haven't seen any information on recent versions of > > the > > >>two RDBMS's that compares the two. My thought seems to be that it's > > like > > >>the VHS vs. Betamax deal - Beta (informix) was a much better format, > > but > > >>VHS (oracle) won anyway because more people used it. I like Informix, > > it > > >>has never given me any problems, it does everything we need, but the > > new > > >>app they want to develop is something they don't want to have to look > > >>too hard to find a good DBA (or two) for and they think Oracle is the > > way > > > > This sounds like a load of old cobblers to me. Chuck out your entire > > database infrastructure because you can't find a DBA? Horse pucky. No, > > in fact, let's rather ask: "Are they f***ing mad?" > > > > >>to go. The Oracle sales nazis have brainwashed them pretty good and > > there's > > >>nothing I can say to sway their opinions. Now the Oracle people have > > > > This is the core of your problem. Oracle make it look so appealing to > > the business user. They hide the technical issues, and management > > probably couldn't give a toss anyway. And they're actually being, um, a > > bit naughty here. > > > > >offered > > >>to swap out Informix for us and replace it with Oracle. My thing is > > that > > >>everything they've mentioned that Oracle is so great at, Informix will > > do. > > > > Plus you have some expertise. Which will all be chucked down the toilet. > > Not your 4GL expertise or for that matter your SQL. > > > > > > > The only thing I can offer is that despite what the sales nazis may say, > > and the fact that conceptually Oracle and Informix look so similar is > > that physical implementation is substantially different. > > > > And although it sounds good (to a manager) to just swap out Informix for > > Oracle, in reality, you'll have to stop all development on all systems > > while you retrain everyone. Then you'll have a couple of months of > > performance problems while you adapt to Oracle's optimisation strategy. > > And even if you do find Oracle DBAs off the shelf, they won't know your > > business for ages. > > > > There are also some interesting differences in Oracle, such as no serial > > datatype. There is a workaround, but you have to manually recode each > > serial field. So all your programmers will need retraining, your support > > staff, any existing DBAs. There will be a massive code change exercise. > > Believe me. > > True but you don't have to do anything with regards to serial types if you > use querix, it is all done for you. In fact we only had to make changes in > about 1 % of our code and not all the line, but for example replacing > MATCHES in an SQL statement to LIKE. > > No comments about the rest, some like pepsi and son Coca-Cola. > > > > > > > > >>Their thing is, where do we find people who know Informix? I would > > just > > >>like somewhere to look for information to hand them that will get them > > >>to consider something else. Any help/information is appreciated... > > > > Ask Informix for help. I haven't seen the original post, so I don't know > > where you are, but Informix should be able to help you. > > > > But in the main, you need to advise management that swapping out > > Informix for Oracle will cause _at_least_ six months of disruption and > > require *massive* retraining and reskilling. There may well be some > > systems which can't be ported for various reasons, leading to a need for > > different database teams. Every single data access statement in all your > > applications will have to be checked for the subtle differences. > > > > Reports which used to run in minutes could take hours until you figure > > out what the problem is. *If* you can figure out what the problem is. > > (Of course, some things could go better as well.) > > > > Even more entertaining are those reports which run fine, but don't > > return the expected results because of those subtle differences. So > > you'll have to run comprehensive reports on existing data, then port to > > Oracle and re-run the reports for comparison. And check each line > > manually. > > > > And any EIS-type stuff like Excel spreadsheets that read the database, > > may need changing too. > > > > I must hasten to say (before Oracle starts shooting at me :-) that if > > you had nothing, t