Daffodil DB / One$DB - How Do They Compare?

capt.mellow asks: "It's been mentioned that Daffodil Software has just released php extensions for their java-based commercial and open-source databases, Daffodil DB and One$DB respectively, enabling these databases as options for running web applications. Personally, I have never heard of these databases before. How do they compare to the likes of Oracle, SQL Server, MySQL, PostgreSQL, Firebird, SQLite, et. al.? Has anyone used them in web applications, and would they care to relate their experiences?"

Comments

its LGPL

[johnjones]

some things to note

you can try it out yourself....
there is a comparision with derby
http://www.daffodildb.com/onedollardb-derby .html

everything depends on what you are using it for

you dont say that in your posting

if you did I might be able to compare and contrast

regards

John Jones

Java's fine for data crunching

[Julian Morrison]

Repetitive CPU-bound work is a strength of JIT compilation. Java should do fine.

You want speed out an RDBMS, the deciding factors are likely to be, in decreasing order of importance: good algorithms, well-designed tables and indexes, fast disk IO, abundant RAM.

Re:Java's fine for data crunching

[fm6]

You're quite correct, though the technology you cite is really out of date. JITs, which reduce whole class files to native code, are a brute force technology that were popular when people first discovered the shortcomings of Java bytecode interpreters. JVMs have evolved a bit since then, and usually rely on dynamic compiling, heuristic inlining, and other sophisticated techniques. This not only has a lower overhead than compiling a whole class every time you load it, it's much more effective in creating fast code.

The creators of the Hotspot VM used to claim that their brainchild would someday outperform C++, because of intelligent optimization at runtime. Don't know if that ever happened.

Gotchas

[Pan T. Hose]

This is an interesting question. The databases you ask about don't have MySQL gotchas, that's for sure. Nor do they have PostgreSQL gotchas. They don't have SQLite gotchas either. Or Oracle gotchas, for that matter. But one thing is sure, trust me, they most certainly do have gotchas of their own. Do you know them? Can you work around them? Will they silently corrupt your data? Will it be easy to migrate your data to other RDBMS without changing your applications? How do they scale? Do they fully support SQL92? SQL99? Can you afford them not to? Are their transactions truly atomic? Is your data always guaranteed to be in a consistent state? Are the operations on your data isolated? Are the transactions durable? What is the developers' relation to the decades of scientific research and engineering experience in the field of relational database management systems? Do they fully understand it? Do they know why you need ACID? Or would they rather tell you that you don't? Those are the questions that you have to answer. When it comes to relational databases, it is always a question of which gotchas are you ready to face. And of course, as I have already written, you will be unable to answer that question without at least some basic understanding of relational algebra, set theory and predicate calculus. Those fields are essential to understand what the relational model is all about.