Re: Comparison of DB2 and Oracle?

From: JEDIDIAH <jedi_at_nomad.mishnet>
Date: Mon, 25 Oct 2004 13:01:43 -0500
Message-ID: <slrncnqg8m.6o8.jedi_at_nomad.mishnet>


["Followup-To:" header set to comp.databases.oracle.server.] On 2004-10-20, Hans Forbrich <news.hans_at_telus.net> wrote:
> Mikito Harakiri wrote:
>
>> Hans Forbrich <news.hans_at_telus.net> wrote in message
>> news:<h3Scd.18205$cr4.15935_at_edtnps84>...
>>> ...functionality that I see required in many
>>> apps such as: workflow, message queueing, replication, subqueries, direct
>>> http request/response capability, security, backup/recovery, admin &
>>> management tools, job scheduler (akin to cron, but inside the DB), DB
>>> initiated callouts to OS shared libraries, DB initiated mail & page, DB
>>> initiated TCP calls, and so on.
>>
>> I alway wondered what is the true value of those bells and whistles.
>> Let's not forget that RDBMS essentially is a SQL execution engine, and
>> everything else should be judged from the perspective how well does it
>> fit into that primary purpose. Therefore, let's go through your list
>> itemized:
>
> The value is simply in having a wheel around that doesn't need to be
> re-invented and maintained.

        No, it just sounds like suitable products need to be selected for each of these tasks rather than just taking an Microsoft Office approach to architecting the system.

>
> No matter how much one explains these away with "isn't it just ...",
> developers always seme to be reinventing these "justs". What you call
> "bells and whistles" seem to be a base requirement in 90% of the projects
> I've seen in the past 3 years - only the developer's don't realize the
> bells are already there so they either build or buy a completely new set.
>
> If that wasn't true, JMS, MQ Series Queuing and Workflow (oh, sorry - it's
> WebSphere now), and the like would not have a reason for being.

        These products have a reason for being because each product represents a specialization in it's own right. If given the choice between a specialist product such as MQ over some element of Oracle bundleware, I would be inclined to go for the IBM product simply because I know that I can count on it to be a discrete component that isn't going to be unecessarily tied to another Oracle product.

>
> Or are you saying - let's get back to commoditizing the SQL engine so we can
> recover some of the revenue from these capabilities? Or continue stretching
> project timelines to accomplish stuff that already exists? <g>

-- 
        Negligence will never equal intent, no matter how you 
attempt to distort reality to do so. This is what separates         ||| 
the real butchers from average Joes (or Fritzes) caught up in      / | \
events not in their control.


                                                     
Received on Mon Oct 25 2004 - 20:01:43 CEST

Original text of this message