<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>What Berkeley DB is not</title>
<link rel="stylesheet" href="gettingStarted.css" type="text/css" />
<meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
<link rel="start" href="index.html" title="Berkeley DB Programmer's Reference Guide" />
<link rel="up" href="intro.html" title="Chapter 1. Introduction" />
<link rel="prev" href="intro_dbis.html" title="What is Berkeley DB?" />
<link rel="next" href="intro_need.html" title="Do you need Berkeley DB?" />
</head>
<body>
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr>
<th colspan="3" align="center">What Berkeley DB is not</th>
</tr>
<tr>
<td width="20%" align="left"><a accesskey="p" href="intro_dbis.html">Prev</a> </td>
<th width="60%" align="center">Chapter 1.
Introduction
</th>
<td width="20%" align="right"> <a accesskey="n" href="intro_need.html">Next</a></td>
</tr>
</table>
<hr />
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a id="intro_dbisnot"></a>What Berkeley DB is not</h2>
</div>
</div>
</div>
<div class="toc">
<dl>
<dt>
<span class="sect2">
<a href="intro_dbisnot.html#id3838528">Berkeley DB is not a relational database</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="intro_dbisnot.html#id3839722">Berkeley DB is not an object-oriented database</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="intro_dbisnot.html#id3839465">Berkeley DB is not a network database</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="intro_dbisnot.html#id3839485">Berkeley DB is not a database server</a>
</span>
</dt>
</dl>
</div>
<p>
In contrast to most other database systems, Berkeley DB provides relatively
simple data access services.
</p>
<p>
Records in Berkeley DB are (<span class="emphasis"><em>key</em></span>,
<span class="emphasis"><em>value</em></span>) pairs. Berkeley DB supports only a few
logical operations on records. They are:
</p>
<div class="itemizedlist">
<ul type="disc">
<li>Insert a record in a table.</li>
<li>Delete a record from a table.</li>
<li>Find a record in a table by looking up its key.</li>
<li>Update a record that has already been found.</li>
</ul>
</div>
<p>
Notice that Berkeley DB never operates on the value part of a
record. Values are simply payload, to be stored with keys and
reliably delivered back to the application on demand.
</p>
<p>
Both keys and values can be arbitrary byte strings, either
fixed-length or variable-length. As a result, programmers can put
native programming language data structures into the database
without converting them to a foreign record format first. Storage
and retrieval are very simple, but the application needs to know
what the structure of a key and a value is in advance. It cannot
ask Berkeley DB, because Berkeley DB doesn't know.
</p>
<p>
This is an important feature of Berkeley DB, and one worth
considering more carefully. On the one hand, Berkeley DB cannot
provide the programmer with any information on the contents or
structure of the values that it stores. The application must
understand the keys and values that it uses. On the other hand,
there is literally no limit to the data types that can be store in
a Berkeley DB database. The application never needs to convert its
own program data into the data types that Berkeley DB supports.
Berkeley DB is able to operate on any data type the application
uses, no matter how complex.
</p>
<p>
Because both keys and values can be up to four gigabytes in length,
a single record can store images, audio streams, or other large
data values. Large values are not treated specially in Berkeley
DB. They are simply broken into page-sized chunks, and reassembled
on demand when the application needs them. Unlike some other
database systems, Berkeley DB offers no special support for binary
large objects (BLOBs).
</p>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="id3838528"></a>Berkeley DB is not a relational database</h3>
</div>
</div>
</div>
<p>
While Berkeley DB does provide a set of optional SQL APIs,
usually all access to data stored in Berkeley DB is performed
using the traditional Berkeley DB APIs.
</p>
<p>
The traditional Berkeley DB APIs are the way that most Berkeley DB
users will use Berkeley DB. Although the
interfaces are fairly simple, they are non-standard in that they
do not support SQL statements.
</p>
<p>
That said, Berkeley DB does provide a set of SQL APIs that behave
nearly identically to SQLite. By using these APIs you can interface
with Berkeley DB using SQL statements. For Unix systems, these APIs
are not available by default, while for Windows systems they are
available by default. For more information, see the
<em class="citetitle">Berkeley DB Getting Started with the SQL APIs</em> guide.
</p>
<p>
Be aware that SQL support is a double-edged sword. One big advantage of
relational databases is that they allow users to write simple
declarative queries in a high-level language. The database system
knows everything about the data and can carry out the command. This
means that it's simple to search for data in new ways, and to ask
new questions of the database. No programming is required.
</p>
<p>
On the other hand, if a programmer can predict in advance how an
application will access data, then writing a low-level program to
get and store records can be faster. It eliminates the overhead of
query parsing, optimization, and execution. The programmer must
understand the data representation, and must write the code to do
the work, but once that's done, the application can be very fast.
</p>
<p>
Unless Berkeley DB is used with its SQL APIs, it has no notion of
<span class="emphasis"><em>schema</em></span> and data types in the way that
relational systems do. Schema is the structure of records in
tables, and the relationships among the tables in the database. For
example, in a relational system the programmer can create a record
from a fixed menu of data types. Because the record types are
declared to the system, the relational engine can reach inside
records and examine individual values in them. In addition,
programmers can use SQL to declare relationships among tables, and
to create indices on tables. Relational engines usually maintain
these relationships and indices automatically.
</p>
<p>
In Berkeley DB, the key and value in a record are opaque to
Berkeley DB. They may have a rich internal structure, but the
library is unaware of it. As a result, Berkeley DB cannot decompose
the value part of a record into its constituent parts, and cannot
use those parts to find values of interest. Only the application,
which knows the data structure, can do that. Berkeley DB does
support indices on tables and automatically maintain those indices
as their associated tables are modified.
</p>
<p>
Berkeley DB is not a relational system. Relational database systems
are semantically rich and offer high-level database access.
Compared to such systems, Berkeley DB is a high-performance,
transactional library for record storage. It is possible to build a
relational system on top of Berkeley DB (indeed, this is what the
Berkeley DB SQL API really is). In fact, the popular MySQL
relational system uses Berkeley DB for transaction-protected table
management, and takes care of all the SQL parsing and execution. It
uses Berkeley DB for the storage level, and provides the semantics
and access tools.
</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="id3839722"></a>Berkeley DB is not an object-oriented database</h3>
</div>
</div>
</div>
<p>
Object-oriented databases are designed for very tight integration
with object-oriented programming languages. Berkeley DB is written
entirely in the C programming language. It includes language
bindings for C++, Java, and other languages, but the library has no
information about the objects created in any object-oriented
application. Berkeley DB never makes method calls on any
application object. It has no idea what methods are defined on user
objects, and cannot see the public or private members of any
instance. The key and value part of all records are opaque to
Berkeley DB.
</p>
<p>
Berkeley DB cannot automatically page in objects as they are
accessed, as some object-oriented databases do. The object-oriented
application programmer must decide what records are required, and
must fetch them by making method calls on Berkeley DB objects.
</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="id3839465"></a>Berkeley DB is not a network database</h3>
</div>
</div>
</div>
<p>
Berkeley DB does not support network-style navigation among
records, as network databases do. Records in a Berkeley DB table
may move around over time, as new records are added to the table
and old ones are deleted. Berkeley DB is able to do fast searches
for records based on keys, but there is no way to create a
persistent physical pointer to a record. Applications can only
refer to records by key, not by address.
</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="id3839485"></a>Berkeley DB is not a database server</h3>
</div>
</div>
</div>
<p>
Berkeley DB is not a standalone database server. It is a library,
and runs in the address space of the application that uses it. If
more than one application links in Berkeley DB, then all can use
the same database at the same time; the library handles
coordination among the applications, and guarantees that they do
not interfere with one another.
</p>
<p>
It is possible to build a server application that uses Berkeley DB
for data management. For example, many commercial and open source
Lightweight Directory Access Protocol (LDAP) servers use Berkeley
DB for record storage. LDAP clients connect to these servers over
the network. Individual servers make calls through the Berkeley DB
API to find records and return them to clients. On its own,
however, Berkeley DB is not a server.
</p>
</div>
</div>
<div class="navfooter">
<hr />
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left"><a accesskey="p" href="intro_dbis.html">Prev</a> </td>
<td width="20%" align="center">
<a accesskey="u" href="intro.html">Up</a>
</td>
<td width="40%" align="right"> <a accesskey="n" href="intro_need.html">Next</a></td>
</tr>
<tr>
<td width="40%" align="left" valign="top">What is Berkeley DB? </td>
<td width="20%" align="center">
<a accesskey="h" href="index.html">Home</a>
</td>
<td width="40%" align="right" valign="top"> Do you need Berkeley DB?</td>
</tr>
</table>
</div>
</body>
</html>
