Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

I'm searching the internet for an auction script that uses a DBI interface for MySQL. I've found a couple, plus one that uses Berkeley DBM. Is this as good? Does it interface with other db's (Oracle, Informix) in case I upgrade? What are the pros & cons of each, and things to be aware of with Berkeley DBM?

I'm not a programmer, so KISS please :)

Replies are listed 'Best First'.
Re (tilly) 1: Berkeley DBM vs. DBI
by tilly (Archbishop) on Feb 04, 2002 at 04:39 UTC
    Berkeley DB is put out by http://www.sleepycat.com.

    It is a very high performance, scalable dbm. A dbm is a very simple type of database, it just does name/value pairs. If you need to look up information in 100 terabytes of data 30,000 times per second, Berkeley DB will be just fine.

    MySQL is an example of a relational database. Relational databases differ from dbms in that they offer a more sophisticated data model for the programmer, you send your requests to them in a language known as SQL (Standard Query Language), and they can find very efficient ways of optimizing complex queries.

    If you want to be able to store more complex information about your auctions, add features, etc, then it probably would be a very good idea to have the extra structure of a relational database. If you just need fast persistent data storage on disk, a simpler dbm will work. But if you turned out to need the features you will find yourself writing a more complex database, except badly.

    If you had to write it yourself, Berkeley DB might be a good choice just because the learning curve is shorter. But if you have a choice between already written ones, MySQL is preferable in my books.

    Incidentally MySQL can run on top of Berkeley DB. In that configuration Berkeley DB stores the information, and MySQL hides the details of keeping things synchronized, maintaining indexes, parsing queries, etc. Also note that scripts which are written using MySQL can usually be easily ported to other relational databases like postgres, Sybase, Oracle and the like.

    UPDATE
    As was pointed out by both rob_au and wmono, I meant to compare relational to dbms, not relational to relational.