The DBM modules work when your data needs can be stored as key/value pairs. You can store more complicated data within key/value pairs with some imagination — for instance, by creating formatted strings that use a comma or some other character to delimit items in the strings, both on the key and the value part of the dictionary. This can be useful, but it can also be very difficult to maintain, and it can restrict you because your data is stored in an inflexible manner. Another way that you can be limited is technical: Note that some DBM libraries limit the amount of space you can use for the values (sometimes to a maximum of 1024 bytes, which is very, very little).
You can use the following guidelines to help determine which of these two types of data storage is appropriate for your needs:
□ If your data needs are simple, use a DBM persistent dictionary.
□ If you only plan to store a small amount of data, use a DBM persistent dictionary.
□ If you require support for transactions, use a relational database. (Transactions are when more than one thing happens at once—they let you keep your data from getting changed in one place but not in another; you get to define what happens concurrently with transactions.)
□ If you require complex data structures or multiple tables of linked data, use a relational database.
□ If you need to interface to an existing system, use that system, obviously. Chances are good this type of system will be a relational database.
Unlike the simple DBM modules, relational databases provide a far richer and more complex API.
Was this article helpful?