The difference between using a DBM and a relational database is the framework that the relational database provides for managing relationships between different kinds of data. If you've never used a relational database, your learning curve will be shorter with a DBM. However learning how to use relational databases definitely pays off over time.
However if you want to use DBMs, I'd suggest using a better one. The one that comes with Perl is SDBM_File, and it has serious limitations. In particular the length of a key/value pair tops out at 1008 bytes. If you use something like DB_File, you'll get rid of that limit.
An incidental tip. Don't worry start to finish about efficiency. That's premature optimization. Instead aim to build it with a sane architecture, and then be prepared to try to optimize it after the fact. | [reply] |
There are really at least two questions - what database backend are you going to use for storage and what programming method are you going to use to access it. In terms of the access method, unquestionably perl's DBI is the most powerful, flexible, and most widely tested and supported. Within DBI you have the option of using SQL or of using various wrappers to DBI that provide more perl-like methods of access. If you intend to do much with databases in the future, you're best off learning at least some SQL.
In terms of the storage mechanism, unless you have previous database experience or have complex or large (hundreds of megabytes) datasets, almost anything will do as a first database - all of the basic operations of DBI are available with even the simplest of backends and whatever you learn will pretty much work the same way if and when you change your backend.
If you already know enough about databases to know about things like transactions and constraints, you'll want a full featured backend like postgreSQL or MySQL accessed through DBI's DBD::Pg and DBD::mysql. PostgreSQL is currently more powerful, and MySQL is currently easier but both those evaluations are changing as both are in constant development. With both of those, you'll need to install a database server.
If you are just starting with databases, you my wish to choose a simpler backend that does not require separate server installation. DBI provides DBD::SQLite, DBD::DBM (which provides a DBI interface to the DBM files you mentioned), DBD::CSV, and DBD::AnyData, DBD::XBase which can all be run without a separate database server and are extremely easy to install. DBD::SQLite and DBD::DBM are faster, DBD::CSV and DBD::AnyData have the ability to store data in human readable files (CSV, fixed-length,XML,etc.), DBD::XBase has the advantage of working with a variety of legacy formats.
Good luck! | [reply] |
Wow! Thanks for all the good info everyone.
My database knowledge is pretty limited so I'm very open to any DB. I have some experience with PostgreSQL but nothing fancy. After reading a bit more I realize I do need the advantages of a relational DB. My project is not going to be very large (maybe a 1 meg at most). I'm also putting this together so other users can access the data so I will eventually need a separate server installation.
I'm going to take a peak at CSV ,AnyData, and XBase. For the mean while I'll use MySQL to keep it simple and get more aquainted with relational db's. After that, as suggested, I'll worry about tuning efficiency.
Thanks again.
| [reply] |
It depends a great deal on what you actually need from your database. DBM stores pretty much nothing more than a hash (actually, less--it stores a mapping from strings to other strings), so if you just need a data store, it may be your best way to go. But a real database offers a lot more ability, at the price of being more complex to deal with. | [reply] |
i realy like SQLite. you should take a look at it.
you need nothing more than the perl module DBD::SQLite | [reply] |
The database that you chose to use for your....database, should be something that you are familiar with. We could get into the in's and out's of database implementations, but lets agree that you don't want to use a flat file on your local filesystem, and that chosing a full blown database system is your best bet.
You should go to the DBI website to see what database implementations it supports, and then chose from there.
good luck.
| [reply] |