> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 28, 2006 3:58 AM > To: Derby Discussion > Subject: Re: Using Derby as a binary store > > Kasper Nielsen <[EMAIL PROTECTED]> 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. > [mjs] 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... > [mjs] Yup. > >>> 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 [mjs] 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.
