I'll give you the same advice I give everyone in a situation similar to yours... make the program fit the data, not the other way around. Things like MLDBM are extensions of a system that was not designed to handle data that was more complex than a simple key => value pair. RDMBS's were designed to handle, you guessed it, relational data!

The power in a RDBMS comes from the ability to normalize your data into units that make it easy to manage, and easy to query and join into ways that may have been computationally expensive or sometimes even untractable in a traditional storage solution. The power of an RDBMS is that the structure of your data is transparent to you, it is it's context and purpose that matters to you. Order doesn't really exist in an RDBMS outside of the order in which you wish to have the data described to you when you extract it. The power of an RDBMD becomes obvious in situations such as this:

supplier_table
id	supplier
1	foo
2	bar
3	baz

item_table
id	item
1	screw
2	bolt
3	stereo

supplier_item_xref
supplier_id	item_id
1	1
1	3
2	2
3	1
3	2
3	3

and let's say you want to see all of the suppliers that happen to supply items screw AND stereo. it would be as saying:

   select
      supplier_table.supplier
   from
      supplier_table,
      item_table,
      supplier_item_xref
   where
      supplier_table.id = supplier_item_xref.supplier_id
      and supplier_item_xref.item_id = item_table.id
      and (item_table.item = 'screw' OR item_table.item= 'stereo');
[download]

this would return to you foo and baz... and all of the processing, the joining, the finding of items, the finding of correlations would be handled by the database engine, instead of having to do it by hand. Usually a database engine will have been optimized MUCH more than you or I could do for general purposes, so it will be able to do this EXTREMELY effectively if you code your queries halfway intelligently.

so now you are asking, why on earth would I use something other than an RDBMS? Well, because often times, your data is NOT relational, the different correlations between different atomic aspects of the data may or may not interest you! You may really just have a record, that can be accessed by a key, and that aspect of the program specification is guaranteed not to change. In cases like this, I go by an old engineers adage, minimize the number of moving parts! If a system's data does not require the complexity inherent in the creation of a relational model, then it is pointless to bring it on!

so, the question you have to ask yourself is, what type of data do I need to store, how does my data need to be retreived, how large will my data set grow? If the answers to these questions point to a simpler answer, then something like a DBM will serve you well, serve you with little overhead, and with minimal added complexity. If however, you see that the system requirements will someday need more advanced access to the data, it is time to invest in learning DBI, SQL, and RDBMS concepts.