Re: OT: How I learned to stop worrying and love the RDBMS

Shawn:

We have used both MySQL and Postgresql to a lesser extent; however, we have
not used either to replace TurboIMAGE for a migration client. We have used
Oracle and DB2 to replace TurboIMAGE for migration clients and our partners
SunGard have used SQL Server quite a bit all with excellent results. We
developed the SQL Server to TurboIMAGE mapping layer (driver) that they use.

A big surprise to me personally over the years is how pervasive and popular
MySQL has become. It is "embedded" in many ancillary (non-TurboIMAGE
replacement) solutions we have implemented for ourselves and our customers
and it just plain works. It is simple and easy to use.

I don't remember ever implementing anything with Postgresql, however it has
also worked very well for the little "experiments" we have done with it.

The migration toolkit that we distribute from SunGard (Transport) has a
TurboIMAGE emulation layer and we have about a 95% implementation of a
driver for MySQL that we developed during idle time for one of our
developers. However, to date, no customer has really shown an interest in
it. That is, no one has gone far enough in that direction so that we would
complete the driver. However, from what I have seen, it should be a more
than acceptable solution as a low cost replacement for TurboIMAGE.

The primary reason for our Oracle, DB2 and MS SQL Server emphasis is because
that is what our paying customers to date have wanted. The one or two
prospects we have encountered for MySQL were not serious in our opinion.

Charles Finley



-----Original Message-----
From: HP-3000 Systems Discussion [mailto:HP3000-L@xxxxxxxxxxxxx] On Behalf
Of Shawn Gordon
Sent: Thursday, July 17, 2008 9:44 PM
To: HP3000-L@xxxxxxxxxxxxx
Subject: Re: OT: How I learned to stop worrying and love the RDBMS

Denys, I tend to use MySQL mostly because my data requirements are
typically modest for what I do for myself or most of my clients (tens
of thousands of records), but I did spend a fair bit of time with
PostgreSQL some years ago and was very amazed at how well it scaled,
even in direct competition with Oracle. I was wondering if you'd
ever spent time comparing the two.

At 06:33 PM 7/17/2008, Denys Beauchemin wrote:
After several years of working with Oracle doing migrations from
MPE/IMAGE
to (Linux/Unix)/Oracle, I thought I would share my opinions with you.

With the continually dropping prices on hardware and the attendant
increase
in hardware performance, selecting an RDBMS as a migration target from
IMAGE
is the only sensible choice.

The capabilities afforded by a proper RDBMS are astounding and are
growing
every year as the hardware continues to increase in price/performance;
the
growth in capabilities is almost geometric.

For IMAGE aficionados, the preceding statement will most probably be seen
as
heresy, but as customers demand more information out of their ever
growing
data repository, the RDBMS has moved far beyond IMAGE.

To my mind, if one is going to migrate from MPE/IMAGE, the goal needs to
be
an RDBMS, preferably one that will have a large suite of products. This
migration is a lot easier if some type of IMAGE-like interface is used on
top of say, Oracle, so the existing programs do not have to be touched,
but
once the migration is complete, the full power of the RDBMS can be
unleashed
and it can co-exist with the programs currently in use.

IMAGE was and still is excellent for computers with limited capabilities,
but when one considers the capabilities of the hardware now and in the
future, the limitations of IMAGE become a real burden. With an RDBMS,
there
are myriad tools (many of them free) that allow you to access the data
VERY
quickly.

Now, I hear what some of you are saying about costs. But let's put a
little
perspective on the subject, you know how I like to go back in history. I
remember what a Series III used to cost, and a 33, and a 68, and a 70 and
then the 935, 950 and so on. We were talking in the hundreds of
thousands
of dollars for systems that could support several dozens of people, up to
about 100. And in those days, $300,000 was a LOT of money; the
mainframes
were in the several millions of dollars. With inflation and so on, these
prices would be staggering today, especially for the power they had then
as
compared to what is available now for hundreds or thousands of dollars.

So, now the costs are more in software, but it is amazing how you can
leverage software to run a business and I believe the RDBMS is about the
best exemplifier of what software leverage is all about. An RDBMS is
foundational, from there everything will flow, or not. If it's difficult
to
get access to the data, you will be fighting that battle over and over
again
and ruing the day you bypassed the RDBMS.

During the last few years, I have become quite comfortable with Oracle,
though I will be the first to tell you that in many ways I have barely
scratched the surface. Oracle is HUGE, (yes it can be in cost also.)
But
as foundational software, it is amazing. The companies that I have
helped
migrate to Oracle have been very pleased to get all these capabilities
heretofore unavailable to them. Going from IMAGE to Oracle is a
veritable
quantum leap and one that is very liberating.

Denys

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *


Regards,

Shawn Gordon
President
theKompany.com
www.thekompany.com
www.mindawn.com
949-713-3276

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

__________ NOD32 3276 (20080717) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

.

Relevant Pages

  • Re: MySQLdb slow on MySQL 5
    ... Oracle bought a small Finnish ... company which developed the transaction-aware table- ... backend for MySQL. ... It's one thing if Oracle fails to comply to all standards, ...
    (comp.lang.python)
  • Re: Oracle vs MySql Performance
    ... Performance on MySql was adequate but as our primary DB platform is ... Oracle we influenced the 3rd part to introduce an Oracle version (NB: ... To facilitate this process the vendor has used almost pure ANSI Sql so ... Look at the wait events in the raw trace file for clues ...
    (comp.databases.oracle.server)
  • Re: Select count(*) in Oracle and MySQL
    ... The same query in Oracle takes about 6 minutes, ... The MySQL table has no primary key either. ... you either don't know how to use a DBMS like Oracle (given ...
    (comp.databases.oracle.server)
  • RE: No more Oracle Standard Edition for VMS
    ... No more Oracle Standard Edition for VMS ... by MySQL. ... mention the impact to the QA/testing group not being able to QA/test new ... Reference the RH Linux site: ...
    (comp.os.vms)