mirror of
https://github.com/MariaDB/server.git
synced 2025-11-10 23:02:54 +03:00
147 lines
9.2 KiB
HTML
147 lines
9.2 KiB
HTML
<!--$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>
|