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

Sounds like good products

[FullMetalAlchemist]

Sounds like good products.

However, there already is SQLite and PostgreSQL that covers the entire spectrum; up untill Oracle is needed.
As I unfortanly doubt that these databases compare to Oracle, so they are in essence racing with a dead horse; it really might be a beautiful dead horse, but it's still dead.

I really like new things, but they are pushing their luck when introducing a database into an already overcrowded market.

never heard of them

[namekuseijin]

But i personaly know PostgreSQL and MySQL, and would definetely go for the former.

You won't be getting DBMSs so much better or more mature than PostgreSQL in the free software world. DBMSs of this quality don't simply spring into existence out of nowhere, hype notwithstanding.

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

Is Java the right language for a RDBMS?

[ptaff]

The product page boasts their RDBMS is written in pure Java.

Databases engines must mainly do hardcore work on large sets of data (index, sort, merge, uniq, manipulate dates...); using Java for data crunching, is that really a neat idea?

Aside from the needed feature set, speed is I think the most important factor when picking up a RDBMS. I guess this is one of the major reasons for the quick adoption of SQLite and the popularity of MySQL vs. PostgreSQL.

Feel ready to own one or many Tux Stickers?

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.

No

[Pan T. Hose]

In this light; is SQLLite really any faster than either MySQL or PostgreSQL in real-life, production situations?

The short answer is: no. The long answer is: it depends on what you mean by real-life, production situations. The real question is: should you worry about it before it starts to be a problem? Or a better question: what do you have to do when it starts to be a problem? And if your applications are designed correctly, the answer is:

shell$ sqlite old-db .dump | psql new-db

and update data sources in your applications. You only have to use abstraction layers in your programs, like DBI in Perl, and all you will have to change is one argument to DBI->connect() and the rest will just work, because PostgreSQL supports a superset of SQLite features. I'm not sure with MySQL, so you'd have to do some research. But the point is that the most important things one should consider while choosing a RDBMS (other than ACID) is the question how easy is it to get your data out of the database and insert it somewhere else, because then the question which database is better in the long run is not so important, for you can always change it later if you want. The keyword is: abstraction layers.

Re:SQLite

[jbolden]

In this light; is SQLLite really any faster than either MySQL or PostgreSQL in real-life, production situations?

SQLLite can be as fast as pure data caching to disk for inserts. When you have data coming into the system so fast that a real RDBMS couldn't handle it (on the same hardware) and are willing to have very slow queries until the data is moved over SQLLite rocks. That's a pretty specialized production situation but I had to implement.