1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
<!--$Id: dbisnot.so,v 10.3 2000/12/14 20:52:03 bostic Exp $-->
<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.-->
<!--All rights reserved.-->
<html>
<head>
<title>Berkeley DB Reference Guide: What is Berkeley DB not?</title>
<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++">
</head>
<body bgcolor=white>
<table><tr valign=top>
<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Introduction</dl></h3></td>
<td width="1%"><a href="../../ref/intro/dbis.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/intro/need.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
<p>
<h1 align=center>What is Berkeley DB not?</h1>
<p>In contrast to most other database systems, Berkeley DB provides relatively
simple data access services.
<p>Records in Berkeley DB are (<i>key</i>, <i>value</i>) 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>
<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>Both keys and values can be arbitrary bit 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>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>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).
<h3>Not a relational database</h3>
<p>Berkeley DB is not a relational database.
<p>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.
<p>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>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>Second, Berkeley DB has no notion of <i>schema</i> 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 indexes on tables. Relational engines
usually maintain these relationships and indexes automatically.
<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.
<p>Berkeley DB does allow programmers to create indexes on tables, and to use
those indexes to speed up searches. However, the programmer has no way
to tell the library how different tables and indexes are related. The
application needs to make sure that they all stay consistent. In the
case of indexes in particular, if the application puts a new record into
a table, it must also put a new record in the index for it. It's
generally simple to write a single function to make the required
updates, but it is work that relational systems do automatically.
<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'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.
<h3>Not an object-oriented database</h3>
<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>Berkeley DB cannot automatically page in referenced objects, 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.
<h3>Not a network database</h3>
<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.
<h3>Not a database server</h3>
<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>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).
<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.
<table><tr><td><br></td><td width="1%"><a href="../../ref/intro/dbis.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/intro/need.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font>
</body>
</html>
|
