sap bought a source license to adabase so they could integrate a in-house db
with sap r3. It has been around for a while. It is a relatively new "open
source" product and it has a paid team of developers working on it.
Also sap said to fortune 500 companies you can run your company using this
db. sapdb has replication and backup utilities and client(windows)
admin/programming tools and a web admin interface that I have not played
with.
marc
----- Original Message -----
From: "Matthew Tedder" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, March 22, 2001 12:34 PM
Subject: Re: DB2 vs. Oracle
It looks interesting... Is it a relatively new product? Maturity is
important. PostgreSQL also has all of what you mention, it is also Object
Relational and has very robust transaction support. The only scalability
limitation that causes me to look at DB2 EE is the transpearant distributed
data/processing capabilities.
The horror of mass "user queries" must be managed and data needs the highest
levels of protection. Even planned increases in daily processes require
consistently more and more performance as time passes. Tape backups are
needed for recovery and reprocessing for what ever reasons. However, quick
dynamic recovery is required for hardware or network failures. All
hospitals and some clinics work 24x7.
If a PostgreSQL has this one additional capability, it would be in the same
leage as DB2 (somewhat comparable but better only in the sense that it
scales in price as well as data/CPU and offers more freedoms in general).
--Matthew
>>> Marc Spitzer <[EMAIL PROTECTED]> 03/22/01 12:07PM >>>
Well for price sapdb is free. It has a perl db interface along with python,
C, C++, Java and odbc. It runs on linux and will soon( I hope) run on
freebsd. It has a replication manager also.
Marc Spitzer
----- Original Message -----
From: "Matthew Tedder" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, March 22, 2001 11:08 AM
Subject: Re: DB2 vs. Oracle
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
