db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dyre.Tjeldv...@Sun.COM
Subject Re: Using Derby as a binary store
Date Tue, 28 Nov 2006 09:57:41 GMT
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.

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


Mime
View raw message