1 files changed, 146 insertions, 0 deletions
diff --git a/bdb/docs/ref/intro/dbisnot.html b/bdb/docs/ref/intro/dbisnot.html
new file mode 100644
index 00000000000..a55fa71763e
--- /dev/null
+++ b/bdb/docs/ref/intro/dbisnot.html
@@ -0,0 +1,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>