Re: [stellation-res] Database abstraction

["Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>]

On Tuesday 13 August 2002 10:11 pm, Florin Iucha wrote:
> On Tue, Aug 13, 2002 at 04:58:41PM -0400, Dave Shields wrote:
> > On Tue, Aug 13, 2002 at 02:06:39PM +0000, Mark C. Chu-Carroll wrote:
> > > So... I'm looking at trying to create a database abstraction layer that
> > > will work accross Postgres, DB2, Oracle, MySQL/InnoDB, and
> > > Firebird.
> >
> > I don't think it's worth that much effort trying to parameterize DDL
> > generation. I suggest making createRepository() a method in the interface
> > AccessPoint (it currently isn't), and letting each implementor provide a
> > complete definition. It would be easier scanning over the hundred or
> > lines of SQL needed than trying to decipher some abstraction layer.
> >
> > The *real* need is to find an open-source relational database that is
> > *easy* to install and provides *acceptable* performance. Postgres is easy
> > to install, but its performance is lacking. I found DB2 harder to
> > install, and sufficiently hard to work with that I don't really have much
> > of a feel for what performance we can expect, and DB2 isn't open-source.
> >
> > By "acceptable performance" I mean something able to handle projects up
> > to 100K lines of code. In the long run we of course want to handle much
> > larger projects, but having this level of performance should suffice to
> > let us continue our work.
> >
> > Having to install a relational database just to play with Stellation as a
> > developer is, I think, a real barrier to entry. We need to find a better
> > relational database soon.
>
> I dare to say that is not true:
>    1. Installing a database is trivial by using a package provided by
>    the distro.
>    2. If you are not using a distro, then you are a power user and do not
>    need any handholding in 'configure && make && make install'
>    3. If you cannot configure and install from source (on UNIX), or you
> cannot create a database, then you are not a "developer".
>
> Please note that I'm not talking about administering or fine-tuning a
> database. Just a "rpm -i/apt-get" and a "createdb".

I don't completely agree with Dave, but I don't completely agree
with you either.

Installing one of the simpler database packages is not a horrribly complicated 
chore.

On the other hand, it's not trivial either. It's not a single step "rpm -i". 
It's a multi-step process. And every time you add a multi-step 
prerequisite, you are driving away potential developers and users.

The latter is far more of a concern to me than the former. To be honest,
if a potential develop isn't willing to figure out how to install and
use a database well enough to run Stellation, I don't think i really
want to see their code in the system.

On the other hand, when the system stabilizes enough for people
to really use it, I think that the RDB installation will be much more
of a barrier. To try out out CVS, all you do is install the CVS rpm. To
try out PRCS, all you do is install a PRCS RPM. To install Stellation,
you need to first get a database running and configured.

If we're trying to recruit developers of other systems to use Stellation,
we need to do a lot of streamlining of the installation and configuration
process.

One of the things that I really want to do in the coming months is
some work on automating the installation process, including doing
the installation and configuration of the underlying database.

Anyway... As far as databases go, Postgres is just about the easiest
to install RDB out there. It installs in a snap, and mostly runs right
out of the box. (For JDBC, you do need to go in a tweak a config
file, but still, it's overall quite easy.) But the performance is, as Dave
said, less than ideal, and the JDBC implementation stinks. The performance
might be addressable. But the JDBC implementation has been awful
for at least two years. And the only "progress" I've seen that time is
a regression, where they removed the LOB support.

> I haven't tried DB/2 lately, but from my memory, aside of creating a
> couple of users and groups, the installation was pretty much flipping
> through a wizard clicking "Next>".

On this point, you are so far from the truth that it's not even funny. 
I *really* want to like DB2. And as an IBM employee, a significant
part of my salary is paid by the money that DB2 generates. So I
have very strong reasons to be biased in its favor.

The first time that I tried to install DB2, it took me three full days
of work. There was a curses based configuration UI, which collected
up a ridiculous number of configuration options, did no validation
whatsoever to make sure that the options were entered correctly,
wrote the options into a file in /tmp, and then ran a bunch of
"rpm -i"'s, which contained scripts that read the configuration file. If
any of the options were wrong, the rpm's would fail, and the install
script would generate no useful diagnostics whatsoever. It was, by
far, the single worst installation process I've ever seen.

It's improved somewhat since then. But it's still awful. And it's not
an "install and run" system. It's one that requires a huge amount of
configuration in order to run your application effectively (or sometimes
to run your application at all). 

My experience with DB2, the reviews of DB2 that I've read,  and my limited 
conversations with people from DB2 group all agree that DB2 is
aimed at working in high load, high performance environments, and
that any application that really needs DB2 will need to do work to
tweak and tune the configuration for that application. As a result, 
no one has really bothered to do much work on building a friendly,
easy to install front end that sets reasonable defaults. Because if
you're using DB2, it's because you have an application that needs
more than the defaults.

	-Mark

-- 
Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center  
*** The Stellation project: Advanced SCM for Collaboration
***		http://www.eclipse.org/stellation
*** Work Email: mcc@xxxxxxxxxxxxxx  ------- Personal Email: markcc@xxxxxxxxxxx