1<!--$Id: dbisnot.so,v 10.8 2002/08/23 20:36:50 bostic Exp $--> 2<!--Copyright (c) 1997,2008 Oracle. All rights reserved.--> 3<!--See the file LICENSE for redistribution information.--> 4<html> 5<head> 6<title>Berkeley DB Reference Guide: What Berkeley DB is not</title> 7<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> 8<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++"> 9</head> 10<body bgcolor=white> 11<table width="100%"><tr valign=top> 12<td><b><dl><dt>Berkeley DB Reference Guide:<dd>Introduction</dl></b></td> 13<td align=right><a href="../intro/dbis.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../intro/need.html"><img src="../../images/next.gif" alt="Next"></a> 14</td></tr></table> 15<p align=center><b>What Berkeley DB is not</b></p> 16<p>In contrast to most other database systems, Berkeley DB provides relatively 17simple data access services.</p> 18<p>Records in Berkeley DB are (<i>key</i>, <i>value</i>) pairs. Berkeley DB 19supports only a few logical operations on records. They are:</p> 20<p><ul type=disc> 21<li>Insert a record in a table. 22<li>Delete a record from a table. 23<li>Find a record in a table by looking up its key. 24<li>Update a record that has already been found. 25</ul> 26<p>Notice that Berkeley DB never operates on the value part of a record. 27Values are simply payload, to be 28stored with keys and reliably delivered back to the application on 29demand.</p> 30<p>Both keys and values can be arbitrary byte strings, either fixed-length 31or variable-length. As a result, programmers can put native programming 32language data structures into the database without converting them to 33a foreign record format first. Storage and retrieval are very simple, 34but the application needs to know what the structure of a key and a 35value is in advance. It cannot ask Berkeley DB, because Berkeley DB doesn't know.</p> 36<p>This is an important feature of Berkeley DB, and one worth considering more 37carefully. On the one hand, Berkeley DB cannot provide the programmer with 38any information on the contents or structure of the values that it 39stores. The application must understand the keys and values that it 40uses. On the other hand, there is literally no limit to the data types 41that can be store in a Berkeley DB database. The application never needs to 42convert its own program data into the data types that Berkeley DB supports. 43Berkeley DB is able to operate on any data type the application uses, no 44matter how complex.</p> 45<p>Because both keys and values can be up to four gigabytes in length, a 46single record can store images, audio streams, or other large data 47values. Large values are not treated specially in Berkeley DB. They are 48simply broken into page-sized chunks, and reassembled on demand when 49the application needs them. Unlike some other database systems, Berkeley DB 50offers no special support for binary large objects (BLOBs).</p> 51<b>Not a relational database</b> 52<p>Berkeley DB is not a relational database.</p> 53<p>First, Berkeley DB does not support SQL queries. All access to data is through 54the Berkeley DB API. Developers must learn a new set of interfaces in order 55to work with Berkeley DB. Although the interfaces are fairly simple, they are 56non-standard.</p> 57<p>SQL support is a double-edged sword. One big advantage of relational 58databases is that they allow users to write simple declarative queries 59in a high-level language. The database system knows everything about 60the data and can carry out the command. This means that it's simple to 61search for data in new ways, and to ask new questions of the database. 62No programming is required.</p> 63<p>On the other hand, if a programmer can predict in advance how an 64application will access data, then writing a low-level program to get 65and store records can be faster. It eliminates the overhead of query 66parsing, optimization, and execution. The programmer must understand 67the data representation, and must write the code to do the work, but 68once that's done, the application can be very fast.</p> 69<p>Second, Berkeley DB has no notion of <i>schema</i> and data types in 70the way that relational systems do. Schema is the structure of records 71in tables, and the relationships among the tables in the database. For 72example, in a relational system the programmer can create a record from 73a fixed menu of data types. Because the record types are declared to 74the system, the relational engine can reach inside records and examine 75individual values in them. In addition, programmers can use SQL to 76declare relationships among tables, and to create indices on tables. 77Relational engines usually maintain these relationships and indices 78automatically.</p> 79<p>In Berkeley DB, the key and value in a record are opaque to Berkeley DB. They may 80have a rich internal structure, but the library is unaware of it. As a 81result, Berkeley DB cannot decompose the value part of a record into its 82constituent parts, and cannot use those parts to find values of 83interest. Only the application, which knows the data structure, can do 84that. Berkeley DB does support indices on tables and automatically maintain 85those indices as their associated tables are modified.</p> 86<p>Berkeley DB is not a relational system. Relational database systems are 87semantically rich and offer high-level database access. Compared to such 88systems, Berkeley DB is a high-performance, transactional library for record 89storage. It's possible to build a relational system on top of Berkeley DB. In 90fact, the popular MySQL relational system uses Berkeley DB for 91transaction-protected table management, and takes care of all the SQL 92parsing and execution. It uses Berkeley DB for the storage level, and provides 93the semantics and access tools.</p> 94<b>Not an object-oriented database</b> 95<p>Object-oriented databases are designed for very tight integration with 96object-oriented programming languages. Berkeley DB is written entirely in the 97C programming language. It includes language bindings for C++, Java, 98and other languages, but the library has no information about the 99objects created in any object-oriented application. Berkeley DB never makes 100method calls on any application object. It has no idea what methods are 101defined on user objects, and cannot see the public or private members 102of any instance. The key and value part of all records are opaque to 103Berkeley DB.</p> 104<p>Berkeley DB cannot automatically page in objects as they are accessed, as some 105object-oriented databases do. The object-oriented application programmer 106must decide what records are required, and must fetch them by making 107method calls on Berkeley DB objects.</p> 108<b>Not a network database</b> 109<p>Berkeley DB does not support network-style navigation among records, as 110network databases do. Records in a Berkeley DB table may move around over 111time, as new records are added to the table and old ones are deleted. 112Berkeley DB is able to do fast searches for records based on keys, but there 113is no way to create a persistent physical pointer to a record. 114Applications can only refer to records by key, not by address.</p> 115<b>Not a database server</b> 116<p>Berkeley DB is not a standalone database server. It is a library, and runs in 117the address space of the application that uses it. If more than one 118application links in Berkeley DB, then all can use the same database at the 119same time; the library handles coordination among the applications, and 120guarantees that they do not interfere with one another.</p> 121<p>Recent releases of Berkeley DB allow programmers to compile the library as a 122standalone process, and to use RPC stubs to connect to it and to carry 123out operations. However, there are some important limitations to this 124feature. The RPC stubs provide exactly the same API that the library 125itself does. There is no higher-level access provided by the standalone 126process. Tuning the standalone process is difficult, since Berkeley DB does 127no threading in the library (applications can be threaded, but the 128library never creates a thread on its own).</p> 129<p>It is possible to build a server application that uses Berkeley DB for data 130management. For example, many commercial and open source Lightweight 131Directory Access Protocol (LDAP) servers use Berkeley DB for record storage. 132LDAP clients connect to these servers over the network. Individual 133servers make calls through the Berkeley DB API to find records and return them 134to clients. On its own, however, Berkeley DB is not a server.</p> 135<table width="100%"><tr><td><br></td><td align=right><a href="../intro/dbis.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../intro/need.html"><img src="../../images/next.gif" alt="Next"></a> 136</td></tr></table> 137<p><font size=1>Copyright (c) 1996,2008 Oracle. All rights reserved.</font> 138</body> 139</html> 140
