Thanks for the link. It does look rather interesting. I wonder how it achieves that
scalability? DB2 Enterprise Extended edition distributes its data and processing
across multiple nodes (even multiple platforms) with no special programming required.
It does this for both high-performance and fault tolerance. That alone is impressive.
My requirement, though, isn't only for extreme scalability in data but also in terms
of price. Hospices get most of everything they own by donations and their
workstations are usually MS-DOS based. One I visited recently had their entire
healthcare application running on MS-DOS based back end and front end systems. Perl
and PostgreSQL are cost-effective for such organizations without sacrificing anything
but extreme scalability.
The importance of hospices and other low-cost healthcare organizations are that :
(1) they need low-cost solutions that keep up with extremely complex and changing
government regulations and equally complex and changing requirements from commercial
payors (insurance companies, etc..). This is 80% of the reason for high costs of
healthcare--in the overhead needed to deal with these requirements--the complexity
really is monumental and not realistically possible for even the largest hospitals
(such as the one I work for). Insurance companies often add complexity in attempts to
make it impossible for us to accurate calculate monies they owe us...You would not
believe the blatantly under-handed practices.
(2) they stand as prospective testing grounds to refine and prove products, hence
making them attractive to larger paying customers.
The healthcare industry today is sorely in need of new technology. The main problem
is in finding people experienced in new technologies who also have a background in
healthcare--because you simply cannot take even the best software engineer from other
fields and expect them to solve these requirements without first spending years in the
industry.
--Matthew
>>> Marc Spitzer <[EMAIL PROTECTED]> 03/22/01 10:44AM >>>
You might want to take a look at sapdb, www.sapdb.org. I have not played
with it but it looks very nice.
Marc Spitzer
----- Original Message -----
From: "Matthew Tedder" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, March 22, 2001 9:48 AM
Subject: Re: DB2 vs. Oracle
When I first attempted using the Oracle DBD, I was given a syntax to use
that allowed me to enter the IP and instance name. But I ended up reading
and writing to tables in a completely different instance. We have test,
development, and production instances and it always went to
development--regardless of what I entered as the SID. Later, I was told
that I needed to enter the SID names in a configuration file, using a
certain syntax.
So my question is--what sense is there in having to enter it in the
connection string? Seems to me also that the connection string method (as
would be done in ASP for example), is the simpler and more versatile method
of doing this anyway.
As per DB2--I am very impressed. I think the lack of a short and simple
tutorial is it's biggest flaw. In another six months, I am planning on
quitting my job and moving to Seattle where I want to try my luck at my own
software company. I've been designing a healthcare application that I would
like to produce in two versions: One for low-income facilities such as
hospices that would be based on PostgreSQL and one for enterprises and large
hospitals based on DB2 Enterprise Extended edition. I've been secretly
working on it for a couple of years now using MySQL (which is very easy to
work with but not sufficient).
At the moment, I am coding on Linux Intel but have also experimented with
OS/360 running under Hercules on Linux. How much are PDP-11s going for
these days?
--Matthew
>>> "Steven N. Hirsch" <[EMAIL PROTECTED]> 03/21/01 06:21PM >>>
On Wed, 21 Mar 2001, Matthew Tedder wrote:
>
> Question:
>
> Oracle has been a royal pain in the ass for us in a couple of
> projects recently done and I am considering switching to DB2. First,
> I need some opinions of feasibility (or, how difficult it'll be
> compared to Oracle):
I may be prejudiced, since I work for IBM, but DB2 is a very slick
product.
> The database itself is on an OS/390 mainframe and the front-end is a
> website based on Perl CGI scripts. Oracle required that the client
> software be installed, configured, and that a text file be updated
> manually. Oracle tables also do not resize themselves dynamically and
> our data is very dynamic, making this a critical need. Individual
> Table size requirements are highly unpredictable--growing and
> shrinking by wide margins in different tables each day.
>
> What all is involved with installing and configuring the drivers and
> Perl DBI modules for DB2? Do the whole clients need to be installed
> as with Oracle? Do I have to explicitly define each connection I will
> be making in config files for it? (That requirement also prevents us
> from using Oracle for another project--if DB2 works better, we'll be
> able to get rid of Oracle on the mainframe and migrate it to Solaris
> for the systems that still require it).
For better or for worse, DB2 requires a "thick" client install _except_ on
Win* and NT where you can have "thin" clients that load DLLs dynamically
from a master application server.
Connections are defined in DB2-ese by 'cataloging' remote nodes (machines,
basically) and adding databases within those nodes to a local database
directory. These operations can be performed either from the Control
Center (a nice Java GUI app) or by entering DML commands into the CLP
(command line processor, somewhat similar to Oracle's SQL> prompt).
The Perl DBD::DB2 driver is full-featured and solid. I think it's
maintained by a person in the DB2 software group in Toronto.
Also, AFAIK IBM does not enjoin you from publishing comparitive benchmarks
as a condition of licensing.
Steve
