Edit File - File Manager

Edit File: dbisnot.html

<html>
<head>
<title>Berkeley DB Reference Guide: What Berkeley DB is not</title>
<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++">
</head>
<body bgcolor=white>
<table width="100%"><tr valign=top>
<td><dl><dt>Berkeley DB Reference Guide:<dd>Introduction</dl></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>
</td></tr></table>
What Berkeley DB is not
In contrast to most other database systems, Berkeley DB provides relatively
simple data access services.
Records in Berkeley DB are (key, value) pairs. Berkeley DB
supports only a few logical operations on records. They are:
<ul type=disc>
<li>Insert a record in a table.
<li>Delete a record from a table.
<li>Find a record in a table by looking up its key.
<li>Update a record that has already been found.
</ul>
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.
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.
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.
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).
Not a relational database
Berkeley DB is not a relational database.
First, Berkeley DB does not support SQL queries. All access to data is through
the Berkeley DB API. Developers must learn a new set of interfaces in order
to work with Berkeley DB. Although the interfaces are fairly simple, they are
non-standard.
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.
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.
Second, Berkeley DB has no notion of schema 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.
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.
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's possible to build a relational system on top of Berkeley DB. 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.
Not an object-oriented database
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.
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.
Not a network database
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.
Not a database server
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.
Recent releases of Berkeley DB allow programmers to compile the library as a
standalone process, and to use RPC stubs to connect to it and to carry
out operations. However, there are some important limitations to this
feature. The RPC stubs provide exactly the same API that the library
itself does. There is no higher-level access provided by the standalone
process. Tuning the standalone process is difficult, since Berkeley DB does
no threading in the library (applications can be threaded, but the
library never creates a thread on its own).
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.
<table width="100%"><tr><td> </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>
</td></tr></table>
Copyright (c) 1996,2008 Oracle. All rights reserved.
</body>
</html>

Back to File Manager