Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by Cliff on from the collective-experiences dept.

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?"

36 comments

  1. Sounds like good products by FullMetalAlchemist · · Score: 3, Interesting

    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.

    1. Re:Sounds like good products by namekuseijin · · Score: 0

      I unfortanly doubt that these databases compare to Oracle, so they are in essence racing with a dead horse

      Yeah, because everyone needs Oracle for all purposes.

      --
      I don't feel like it...
    2. Re:Sounds like good products by FullMetalAlchemist · · Score: 1

      Maybe you can't read, I wrote that SQLite and PostgreSQL covers the entire spectrum up till Oracle; that means that there is no need for another database other than those three.
      I personally use a few more, but I would do away with DB2 if I could.

    3. Re:Sounds like good products by YakumoFuji · · Score: 1

      you would do away with DB2?? ouch!

      you have obviously never used an AS400. They rock the house as the OneTrueDatabaseServer. Even oracle isnt on par to running an AS400.

      If you wanna ditch something, Id go culling in the midrange, so you have something lowend (sqlite), something midrange (firebird or postgress) and something on the topend (os400+db2)...

      thin the ranks a little....

      --

      no sig for you
    4. Re:Sounds like good products by FullMetalAlchemist · · Score: 1

      True, but only 3 of the clients run OS/400.

      And for those three it would be better to use Oracle, simply because all the people working with their DB2 installations knows Orcale better.
      Knowledge is more valuable than the product itself.

      Most Oracle clients are considering migrating to PostgreSQL during next buisness "year", now that it runs natively on Windows; to simplify the development and testing, thereby reducing TCO.

      To be frank, AS/OS/400 experts are hard do come by, and sadly they often tend to live in an alternate universe.

    5. Re:Sounds like good products by afabbro · · Score: 1
      Most Oracle clients are considering migrating to PostgreSQL during next buisness "year"

      Bwaaaahahahaha. Man, that is funny. Where did you hear such nonsense?

      now that it runs natively on Windows; to simplify the development and testing, thereby reducing TCO.

      What does that have to do with anything? It's run natively on Linux for a long time if cheap platform was the main consideration.

      I'm not saying they shouldn't move or they couldn't move (though in many cases, some Oracle features do prevent switching), but really, "most oracle clients"? I think not.

      --
      Advice: on VPS providers
    6. Re:Sounds like good products by Anonymous Coward · · Score: 0

      You might want to try to write a working web page before trying to teach others to write an operating system.

    7. Re:Sounds like good products by FullMetalAlchemist · · Score: 1

      Most Oracle clients are considering migrating to PostgreSQL during next buisness "year"
      Bwaaaahahahaha. Man, that is funny. Where did you hear such nonsense?


      Guess what? From our clients that use Oracle!



      now that it runs natively on Windows; to simplify the development and testing, thereby reducing TCO.

      What does that have to do with anything? It's run natively on Linux for a long time if cheap platform was the main consideration.


      Because most of their own developers use Windows.
      Instead of everyone having an expensive Oracle installation on their desktops (not economically feasible) or everyone sharing a testbed server, each development team is completely independent from what the others are doing; this is security reasons, or in short, economics.


      I'm not saying they shouldn't move or they couldn't move (though in many cases, some Oracle features do prevent switching), but really, "most oracle clients"? I think not.


      Indeed, we have been pushing for PostgreSQL for several years, but management refuses to run something that doesn't run on Windows.
      Thankfully, this has changed, and while the bigger institutions will not switch, almost all medium and small clients will not upgrade or purchase more Oracle licenses.

      In enterprise terms, a switch.
    8. Re:Sounds like good products by Anonymous Coward · · Score: 0

      the wiki works fine here.

    9. Re:Sounds like good products by Anonymous Coward · · Score: 0

      Oracle allows provides free download and use of their products for developement purposes. Every developer can have a copy of Oracle on their desktop without a problem. It's production instances you have to pay for.

    10. Re:Sounds like good products by FullMetalAlchemist · · Score: 1

      Really, that's great, but we have finally convinced most of them to switch and that really help us as consultants who specialize on PostgreSQL. :)

      Anyway, you could supply a link and I'm sure it will be well recieved by many here on /.

    11. Re:Sounds like good products by russ_allegro · · Score: 1

      Last time I looked Oracle was free to install for a development machine. So it would actually be cheaper for them to develop on Oracle since that is their production database.

      I do like PostgreSQL though.

  2. never heard of them by namekuseijin · · Score: 4, Insightful

    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.

    --
    I don't feel like it...
    1. Re:never heard of them by Anonymous Coward · · Score: 0

      Have you heard of Ingres. It's a full fledged DBMS that some might argue is better and more mature than PostgreSQL (close enough that it could be argued either way for a long time).

      Although Ingres was free a long time ago (it was the starting point for the original Postgres), it was made commercial before it was a full fledged DBMS and stayed commercial for decades.

      Now it has been open sourced. In one sense (from the point of view of free software) Ingres has "sprung into existance".

      More on topic, maybe the original poster doesn't need a "better" or mature DBMS (PostgreSQL or Ingres). Perhaps the many features of Ingres or PostgreSQL are simply not important, but being able to run everything in a jvm are.

      If the posters interest was due to the recent support for PHP, running in a jvm is probably not an important requirement (and I understand that the dbs asked about are written in java).

      Horse for courses (as usual). And in this case the course is unknown.

    2. Re:never heard of them by Anonymous Coward · · Score: 0

      Have you heard of Ingres.

      Yes, it's been around for years (as you pointed out.)

      In one sense (from the point of view of free software) Ingres has "sprung into existance".

      BULLSHIT.

      If you're gonna quote someone, you should include the entire quote - if you go back and check, you'll see that the end of that sentence is "from out of nowhere."

      As Ingres has been around for a *very* long time, it can hardly be considered having sprung from out of nowhere.

  3. its LGPL by johnjones · · Score: 3, Informative

    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

  4. Is Java the right language for a RDBMS? by ptaff · · Score: 2, Insightful

    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?

    1. Re:Is Java the right language for a RDBMS? by comwiz56 · · Score: 1

      Contrary to popular belief, Java code is almost as fast as code written in C or $COMPILED_LANGUANGE_OF_CHOICE. It actually assembles much of its code in a machine specific state before running, allowing it to run at close the speed of comparable languages.

    2. Re:Is Java the right language for a RDBMS? by Bastian · · Score: 1

      It can run as fast as it wants once it makes it into the CPU. I'm still pretty sure the real reason why Java programs run so slowly on my computer is related to the horrible noises that the disk containing the swapfile makes whenever I try to run a Java program on a computer without a fairly large amount of physical memory.

    3. Re:Is Java the right language for a RDBMS? by Anonymous Coward · · Score: 0

      It's not so much that a database written in Java is a bad thing, but a Java database has a LOT more value to a Java application in that it can be embedded, you can leverage your Java skill sets to manage, administrate or expand the database etc.

      As far as a for a standalone database server, I'd go with something more common, like Postgres or MySQL, especially in the PHP market. There's no reason to take the foot print hit of Java for a commodity DB server if there are other viable options.

      And I'm a "Java Fanboy(tm)".

  5. SQLite by mwvdlee · · Score: 1

    Just some small questions about SQLite. I like the idea of it being really tiny and uses a single file as a database, makes is possible to ship a tiny DB with small applications.

    I am however doubtful of it's performance. It is clear from the performance measurements that SQLite is only faster than MySQL when it is running asynchronous or in transaction mode. AFAIK in both these modes, any problem in the SQL statement would invalidate the entire list of SQL statements. It seems than that in most practical situations you'd either have small or no transactions you'd want safely on disk ASAP, which would basically offset the performance gain in a negative way. In this light; is SQLLite really any faster than either MySQL or PostgreSQL in real-life, production situations?

    --
    Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    1. Re:SQLite by snorklewacker · · Score: 1

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

      You would never use it for "production situations" when you need an actual RDBMS. SQLite's niche is more like when you need something better than ndbm but not a full blown RDBMS (That said, it actually has more mature SQL support than MySQL). In that respect, it is blazing fast. I have stored a million-row logfile type of database on it and with some simple filter queries, got results literally 20 times faster than on MySQL. You can get away with a lot when you know you have the whole database locked. For complex queries, I'd move all the way up to postgresql. MySQL is pretty much a non-starter with me, but that's a rant all its own.

      --
      I am no longer wasting my time with slashdot
    2. Re:SQLite by jbolden · · Score: 2, Interesting

      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.

  6. Java's fine for data crunching by Julian+Morrison · · Score: 2, Informative

    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.

    1. Re:Java's fine for data crunching by tcopeland · · Score: 1

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

      Right on, the JIT will do the job once the data gets into memory. And if the guys developing the DB backend need to, they can always use the Java NIO packages to make moving data to/from the disks faster. Good times all around.

      --
      The Army reading list
    2. Re:Java's fine for data crunching by fm6 · · Score: 2, Informative
      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.

  7. Gotchas by Pan+T.+Hose · · Score: 2, Informative

    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.

    --
    Sincerely,
    Pan Tarhei Hosé, PhD.
    "Homo sum et cogito ergo odi profanum vulgus et libido."
    1. Re:Gotchas by fm6 · · Score: 1
      I was nodding my head in agreement until I got to the very end of your post, and you started listing formal logic topics that are way beyond the scope of day-to-day database design. That kind of rigorous theory is useful for designing a query engine or picking nits with the fine points of various SQL dialects. But I submit that it's serious overkill to insist that every database designer make a serious study of these topics. To really get a useful grasp of these topics, you'd have to do more than read a few Wikipedia articles or buy a couple of books. A full semester of upper-division college courses would be more like it. Which is really overkill for most database developers.

      I do agree that there's not enough understanding of these topics in the database community. But what's needed is more practical stuff. Like an intuitive knowledge of database normalization. Not sophisticated formalisms that are difficult to learn and rarely applied.

    2. Re:Gotchas by jbolden · · Score: 1

      I'm going to disagree on that last line as well. I have a PhD in number theory so I understand relational algebray, set theory... I'd say the only thing you really need is one time to have seen that 3rd normal form is the criteria to have table operations be associative and understand what that means. That's a single 1 1/2 hr lecture not a series of courses.

  8. No by Pan+T.+Hose · · Score: 2, Interesting

    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.
    --
    Sincerely,
    Pan Tarhei Hosé, PhD.
    "Homo sum et cogito ergo odi profanum vulgus et libido."
    1. Re:No by mwvdlee · · Score: 1

      I meant with regards to performance only.

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
  9. Ask Slashdot: by sootman · · Score: 1

    How are you supposed to pronounce 'One$DB'?

    --
    Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
    1. Re:Ask Slashdot: by Wolfkin · · Score: 1

      Well, I'd assumed it would be "one dollar dee bee".

      --
      Property law should use #'EQ, not #'EQUAL.
    2. Re:Ask Slashdot: by Anonymous Coward · · Score: 0

      How are you supposed to pronounce 'One$DB'?

      Clearly, $DB is a variable corresponding to the database you're really using. So if you were using PostgreSQL, you'd pronounce it "one-post-gress-queue-ell".

  10. Daffodil DB and Compiere (open source ERP) by ehoff · · Score: 1

    Compiere an open source ERP project typically requires Oracle (although other DBs are supposedly in the works) but now you can also use Daffodil:
    http://daffodildb.com/daffodil-compiere.html/
    I haven't tried it yet... has anyone else?