db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <de...@segel.com>
Subject RE: Using Derby as a binary store
Date Tue, 28 Nov 2006 13:34:56 GMT

> -----Original Message-----
> From: Dyre.Tjeldvoll@Sun.COM [mailto:Dyre.Tjeldvoll@Sun.COM]
> Sent: Tuesday, November 28, 2006 3:58 AM
> To: Derby Discussion
> Subject: Re: Using Derby as a binary store
> Kasper Nielsen <news@kav.dk> writes:
> > David Van Couvering wrote:
> >> To be honest, this looks more like a job for BDB than for Derby.  I
> >> would love to see the Derby store API made public at some point, but
> >> currently it's not public and I suspect it may be difficult to work
> >> with.  Are there reasons BDB/Java won't work for you?
> >
> > Not besides the license:)
> It's a shame isn't it?
> > Its for an BSD licensed project, so BDB is pretty much out of the
> picture.
> >
> > And since I haven't been able to find any projects resembling BDB my
> > hope was that I could use Derby with some minor tweaking.
> I think you can safely assume that it will be MAJOR tweaking. Or
> perhaps we should say "a considerable effort". Perhaps to the point
> where it is easier to write what you need from scratch.
> Aren't there some non-transactional/non-db based persistence
> frameworks out there? Maybe you could implement what you need on top
> of them.
Scalability is going to be an issue then.

You are correct. It would be easier to write what he needs from scratch.

> I agree with David that you should really try using the SQL interface
> and benchmark it before you conclude that you cannot afford it. For
> the use cases you describe the SQL should not be that difficult, and
> you should be able to hide it in library of methods that the rest of
> your code can use (there are frameworks that will do that for you,
> e.g. IBATIS).
> If you make sure that those queries are prepared only once and then
> reused, and that they use indices sensibly, this should perform well.
> If you care about performance you should think twice about using
> frameworks that promise to "do all the hard work" and generate the
> SQL for you. There have been countless examples of such
> frameworks (I won't name any) producing completely brain-dead SQL...

> >>> indexing/transactional features of Derby instead. However, I'm not
> >>> willing to pay the performance cost for using SQL since I'm only
> >>> storing byte[] arrays (if it is possible).
> Try it! Write a simple app, or use the simple client found under
> DERBY-1961 and profile it. The cost of compiling the SQL is only done
> once and "amortized" across the uses the prepared statement.
> Maybe you can modify the DERBY-1961 to use the data type need. Then
> you can see if the performance is acceptable...
> --
> dt
The simplest path would be to write his own from scratch.
The questions that haven't been asked:
1) Are there other pieces of the application that may benefit from being in
a relational database.
2) What is the use case of the application? And what are the future
enhancements that are already planned?

That should be your driving reason for using a database. Choosing a database
that doesn't support the data type you wish to use would mean 1) Either a
rethink of your application to use a different solution so that it would map
to the database better. Or 2) Choose a more appropriate storage model.

View raw message