Personally, I think there's no comparison between Derby and SQLite. Derby's an actual database with "all" the bells and whistles, but still a really compact size. SQLite is an extremely fast database-like system with a much smaller subset of features and SQL compliance. Plus, if you're writing in Java, go with Derby. If you're writing in C or C++, give SQLite a run-through.
Off the top of my head, SQLite doesn't support foreign key constraints, or use column types (everything is a string, unless it's an int, which is actually a string). In the quirks department, I've noticed join order can have a dramatic effect on performance. What's really nice is that the whole database is a single file, which makes using it as a save file in your application really nice. Also, startup times are zero. I think Derby takes a second or two to startup. Both systems support transactions. Derby can be used in a multi-user mode, while SQLite is strictly mono-user. I know both databases claim to be zero-administration, but I'd say SQLite more serious about it. I don't even know how to configure SQLite. Derby certainly works great without administration, but there are a whole lot of options you can muck with if you like. My two cents, ry > In another thread I recently wrote "I'm happy with the way that Derby > has behaved, but I'd like to ask a provocative question nevertheless..." > > Back in the summer, when I told my son (who is a computer > professional) that I had a Masters student porting my MySQL db to > Derby, he told me I should be using SQLite, which is what Google is > using in its Gears thing. I persisted with Derby, mainly because it > is Java and my app was in Java, but I'd be interested to know what > people regard as the relative strengths of weaknesses of the two > embedded DBs. > > David > > > >
