Re: How to choose a DB

Mark Townsend wrote:
>
> Tim Schaefer wrote:
> >
> > Mark,
> >
> > My comments below...
> >
> [Snip}
>
> Tim - we have had this conversation before.
>
> > You can use Informix's 4GL or whatever to link to the engine, and the
> > engine takes care of the details of bringing back the query.
>
> 'Bringing back the query' - it's interesting that you continue to talk
> about cluster support solely in a data warehousing environment - a
> scenario that by implicit design does not introduce many across node
> resource management issues.
>

Uhm, not sure what you're talking about but perhaps it's because you have a more limited view with Oracle. This would be a limited view not because of Oracle alone, but because you've never really seen how much easier Informix is to use on SMP or MPP.

Oracle is strictly SMP, never going the distance with real MPP, but that's ok, it seems to work for a lot of sites. But the question is, if you're going to go strictly SMP, why not use a more up to date engine? Oracle sets up a lot of data bases to cover the limitations of Oracles' engines. This is I suspect to allow the users to work around the older kind of technology in your engines. And that covers OLTP as well as DSS. Again, superior marketing makes up for a world of sins in the product development department.

> > Informix's XPS on the other hand has an unlimited scalability
>
> Can I ask you a question - exactly how many XPS deployments have you
> touched, seen or even heard about, under OLTP applications, that do have
> unlimited scalability ?
>

OK, good point, I've worked on XPS over a year, on a DSS system. I've been working with Informix's OLTP since 1987, and this includes all sizes of systems. Informix is a whole lot more scalable and simple to implement than Oracle ever will be, especially in light of a fail-over system, which Informix has by the way.

Hey, can you bring back more than one row with your stored procedures? I don't think so.  

> I had presumed that Miguel was looking for an clustered OLTP solution -
> and the simple truth is that an OLTP solution deployed on an cluster
> needs to be designed to make efficient use of the cluster for
> scalability. This is NOT an Oracle limitation, it is simply a speed of
> light issue.
>

I'm not so sure clustering SMP systems together is such a good idea, and in your following context it sounds muddy.  

> For example, here's a simple 'real world' environment for you -
>
> Assume a problem reporting system - say for a telco. Customers talk to
> call takers who log trouble tickets in a database. The trouble tickets
> are then analysed (either by hardware/software, or by people) to
> determine the nature of the problem. Once analysed, inventory and
> services are then reserved and dispatched to deal with the problem.
>
> This system has to be highly available as there are business penalties
> involved for not resolving problems within strict service level
> guidelines.
>
> It needs to support up to 1000 concurrent call takers perhaps logging up
> to 200K calls a day, potentially 1 million inventory and resource items
> (that are geographically spread), and around 400 field technicians, who
> receive work order notification by RDT from the dispatch system.
>
> You can assume that no single SMP box can carry all the load.
>

You *can* make this assumption, but I do understand where you're headed.

> Given a hardware cluster of your choosing, how would you architect the
> workload on this system to meet both availability and scalability
> requirements ? There is a right answer, and a wrong answer.
>
> Clusters under a data warehouse or active/passive OLTP is relatively
> easy. Clusters under an active/active OLTP application require a lot of
> thought, no matter what technology is used. There are no magic bullets
> (Yet)
>

Well, in Oracle's case there's a lot more hardware involved because of the Borg-like invasion of a system that Oracle sets up. I've never seen more directories in my life! What a mess. And all those engines and stuff. Very complicated. Informix is a whole lot simpler no matter how you slice it ( or dbslice it :-) ) than Oracle will ever be simply because Oracle's architecture is bolt-on, band-aids and bailing wire. In the near future you will see Oracle not only fall behind but fall behind in a major way because of the superior scaling and architecture in Informix. Certainly, Informix's engines aren't perfect, but they are a whole lot easier to scale.  

> > On Oracle you get back data one-server-at-a-time ( reading from Oracle
> > docs )
 

> > Oracle on the other hand forces
> > you to deal with the selected set individually--
>
> This is Simply Not True (tm)
>
> You are basing your Oracle knowledge on a version of the product (7.3)
> and some accompanying third party documentation (albeit published by
> Oracle Press) that is now over 5 years old.
>

OK, well, your company is still selling the books and still preaching this. Someday your docs will be current with your marketing. :-)

> > Oracle hasn't upgraded their engines,
> > in what, 10 years?? The only thing I see updated is the marketing
> > materials.
>
> The engine is continually updated with each release - an example of this
> in Oracle8i Parallel Server is the new Cache Fusion technology that can
> use new OS User Mode IPC mechanisms to reduce the cost of an inter node
> memory call - significantly reducing the need to go to disk for data
> shipment, and eliminating much of the context switch load.
>

Sounds great, almost as good as what Informix has had for several years.

:-)  

> --
> Regards,
>
> Mark Townsend

PS to Kudzi, no I don't work for Informix's marketing department, they don't have one. :-) Which explains why Oracle does much better.

Happy New Year to all!

-- 
.
.-
.--
.---
.----  Tim Schaefer
.----- tschaefe_at_bellsouth.net
.----  http://www.inxutil.com
.---   
.--
.-
.