Date: Tue, 17 Feb 2015 17:25:57 +0000 Subject: Imported from /home/lorry/working-area/delta_berkeleydb/db-6.1.23.tar.gz. --- docs/programmer_reference/intro_dbisnot.html | 312 +++++++++++++++------------ 1 file changed, 170 insertions(+), 142 deletions(-) (limited to 'docs/programmer_reference/intro_dbisnot.html') 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 @@

Library Version 11.2.5.3

Library Version 12.1.6.1

@@ -22,9 +22,7 @@ - +

Prev	Chapter 1. - Introduction -	Chapter 1. Introduction	Next

@@ -42,226 +40,256 @@

- Berkeley DB is not a relational database + Berkeley DB is not a relational database
- Berkeley DB is not an object-oriented database + Berkeley DB is not an object-oriented database
- Berkeley DB is not a network database + Berkeley DB is not a network database
- Berkeley DB is not a database server + Berkeley DB is not a database server

- In contrast to most other database systems, Berkeley DB provides relatively - simple data access services. +

+ 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: + value) pairs. Berkeley DB supports + only a few logical operations on records. They are:

Insert a record in a table.
Delete a record from a table.
Find a record in a table by looking up its key.
Update a record that has already been found.
+ Insert a record in a table. +
+ Delete a record from a table. +
+ Find a record in a table by looking up its + key. +
+ Update a record that has already been + found. +

- 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.

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.

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.

- 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 BLOB support for more + information.

Berkeley DB is not a relational database

- 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.

- 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. +

+ 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.

- 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 - Berkeley DB Getting Started with the SQL APIs 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 + Berkeley DB Getting Started with the SQL APIs guide.

- 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. +

+ 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.

- 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. +

+ 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.

- Unless Berkeley DB is used with its SQL APIs, it 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. +

+ Unless Berkeley DB is used with its SQL APIs, it 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 + 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 is possible to build a - relational system on top of Berkeley DB (indeed, this is what the +

+ 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.

Berkeley DB is 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. +

+ 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. +

+ 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.

Berkeley DB is 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. +

+ 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.

Berkeley DB is 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. +

+ 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.

- 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. +

+ 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.

-- cgit v1.2.1