Keys in the Btree are stored in sorted order, and the relationship between them is defined by that sort order. The default sort order is lexical, but applications may provide any sort order they choose. For this reason, the Btree access method should be used when there is a locality of reference between keys. Locality of reference means that accessing one particular key in the Btree means that the application is more likely to want to access keys that are somehow related to the key being accessed. For example, if keys are timestamps, and it's likely that a request for an 8AM timestamp will be followed by a request for a 9AM timestamp, the Btree access method is generally the right choice. Or, for example, if the keys are individual surnames, and the application will want to review all individuals with the same last name, the Btree access method is again the right choice.
The Hash access method should be used when there is no locality of reference between keys.
The Recno access method should be used when it is desirable to store and retrieve records based on logical record numbers.
It is possible to store and retrieve records based on logical record numbers in the Btree access method. However, those record numbers are always mutable, i.e., as records are deleted or inserted, the logical record number for other records in the database can change. The Recno access method can be configured to run in either mutable or fixed mode: mutable, where logical record numbers change as records are deleted or inserted, and fixed, where record numbers never change regardless of the database operation. Generally, the Recno access method should be used when the primary method for accessing the database is a logical record number.)
In addition, the Recno access method provides support for databases whose permanent storage is a flat text file and the database is used as a fast, temporary storage area while the data is being read or modified.
Because the access method implementation unavoidably interacts with the application's data set, locking requirements and data access patterns, using one access method instead of another can sometimes provide superior performance. For applications whose data can potentially be stored in more than one type of database, it may be useful to benchmark the application's performance using the two access methods.
One of the strengths of Berkeley DB is that it provides multiple access methods and provides almost identical interfaces to the different access methods. Because of this, it is a simple task to modify an application to use a different access method. This allows applications to benchmark the different Berkeley DB access methods against each other for their particular data set and access pattern.