diff options
| author | Lorry Tar Creator <lorry-tar-importer@baserock.org> | 2015-02-17 17:25:57 +0000 |
|---|---|---|
| committer | <> | 2015-03-17 16:26:24 +0000 |
| commit | 780b92ada9afcf1d58085a83a0b9e6bc982203d1 (patch) | |
| tree | 598f8b9fa431b228d29897e798de4ac0c1d3d970 /docs/programmer_reference/intro_dbisnot.html | |
| parent | 7a2660ba9cc2dc03a69ddfcfd95369395cc87444 (diff) | |
| download | berkeleydb-master.tar.gz | |
Diffstat (limited to 'docs/programmer_reference/intro_dbisnot.html')
| -rw-r--r-- | docs/programmer_reference/intro_dbisnot.html | 312 |
1 files changed, 170 insertions, 142 deletions
diff --git a/docs/programmer_reference/intro_dbisnot.html b/docs/programmer_reference/intro_dbisnot.html index 3b1a68d9..4e5a93a9 100644 --- a/docs/programmer_reference/intro_dbisnot.html +++ b/docs/programmer_reference/intro_dbisnot.html @@ -14,7 +14,7 @@ <body> <div xmlns="" class="navheader"> <div class="libver"> - <p>Library Version 11.2.5.3</p> + <p>Library Version 12.1.6.1</p> </div> <table width="100%" summary="Navigation header"> <tr> @@ -22,9 +22,7 @@ </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> + <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> @@ -42,226 +40,256 @@ <dl> <dt> <span class="sect2"> - <a href="intro_dbisnot.html#idm1802280">Berkeley DB is not a relational database</a> + <a href="intro_dbisnot.html#idm1825416">Berkeley DB is not a relational database</a> </span> </dt> <dt> <span class="sect2"> - <a href="intro_dbisnot.html#idm2288920">Berkeley DB is not an object-oriented database</a> + <a href="intro_dbisnot.html#idm1180680">Berkeley DB is not an object-oriented database</a> </span> </dt> <dt> <span class="sect2"> - <a href="intro_dbisnot.html#idm2354536">Berkeley DB is not a network database</a> + <a href="intro_dbisnot.html#idm2742952">Berkeley DB is not a network database</a> </span> </dt> <dt> <span class="sect2"> - <a href="intro_dbisnot.html#idm2301256">Berkeley DB is not a database server</a> + <a href="intro_dbisnot.html#idm940752">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> + 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: + <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> + <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. + 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. + 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. + 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). + 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. By default 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. However, you can configure Berkeley DB + to treat large objects in a special way, so that they are + accessed in a more efficient manner. Note that these + specially-treated large objects are not confined to the four + gigabyte limit used for other database objects. See <a class="xref" href="blobs.html" title="BLOB support">BLOB support</a> for more + information. </p> <div class="sect2" lang="en" xml:lang="en"> <div class="titlepage"> <div> <div> - <h3 class="title"><a id="idm1802280"></a>Berkeley DB is not a relational database</h3> + <h3 class="title"><a id="idm1825416"></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. + 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> + 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. + 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> + 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> + 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> + 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 + 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 + <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. + 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="idm2288920"></a>Berkeley DB is not an object-oriented database</h3> + <h3 class="title"><a id="idm1180680"></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> + 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> + 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="idm2354536"></a>Berkeley DB is not a network database</h3> + <h3 class="title"><a id="idm2742952"></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> + 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="idm2301256"></a>Berkeley DB is not a database server</h3> + <h3 class="title"><a id="idm940752"></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> + 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> + 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> |