diff options
Diffstat (limited to 'bdb/docs/ref/intro')
| -rw-r--r-- | bdb/docs/ref/intro/data.html | 54 | ||||
| -rw-r--r-- | bdb/docs/ref/intro/dbis.html | 159 | ||||
| -rw-r--r-- | bdb/docs/ref/intro/dbisnot.html | 146 | ||||
| -rw-r--r-- | bdb/docs/ref/intro/distrib.html | 28 | ||||
| -rw-r--r-- | bdb/docs/ref/intro/need.html | 60 | ||||
| -rw-r--r-- | bdb/docs/ref/intro/products.html | 69 | ||||
| -rw-r--r-- | bdb/docs/ref/intro/terrain.html | 248 | ||||
| -rw-r--r-- | bdb/docs/ref/intro/what.html | 53 | ||||
| -rw-r--r-- | bdb/docs/ref/intro/where.html | 39 |
9 files changed, 0 insertions, 856 deletions
diff --git a/bdb/docs/ref/intro/data.html b/bdb/docs/ref/intro/data.html deleted file mode 100644 index e9d6ead064d..00000000000 --- a/bdb/docs/ref/intro/data.html +++ /dev/null @@ -1,54 +0,0 @@ -<!--$Id: data.so,v 10.1 2000/09/22 18:23:58 bostic Exp $--> -<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.--> -<!--All rights reserved.--> -<html> -<head> -<title>Berkeley DB Reference Guide: An introduction to data management</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/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/intro/terrain.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>An introduction to data management</h1> -<p>Cheap, powerful computing and networking have created countless new -applications that could not have existed a decade ago. The advent of -the World-Wide Web, and its influence in driving the Internet into homes -and businesses, is one obvious example. Equally important, though, is -the from large, general-purpose desktop and server computers -toward smaller, special-purpose devices with built-in processing and -communications services. -<p>As computer hardware has spread into virtually every corner of our -lives, of course, software has followed. Software developers today are -building applications not just for conventional desktop and server -environments, but also for handheld computers, home appliances, -networking hardware, cars and trucks, factory floor automation systems, -and more. -<p>While these operating environments are diverse, the problems that -software engineers must solve in them are often strikingly similar. Most -systems must deal with the outside world, whether that means -communicating with users or controlling machinery. As a result, most -need some sort of I/O system. Even a simple, single-function system -generally needs to handle multiple tasks, and so needs some kind of -operating system to schedule and manage control threads. Also, many -computer systems must store and retrieve data to track history, record -configuration settings, or manage access. -<p>Data management can be very simple. In some cases, just recording -configuration in a flat text file is enough. More often, though, -programs need to store and search a large amount of data, or -structurally complex data. Database management systems are tools that -programmers can use to do this work quickly and efficiently using -off-the-shelf software. -<p>Of course, database management systems have been around for a long time. -Data storage is a problem dating back to the earliest days of computing. -Software developers can choose from hundreds of good, -commercially-available database systems. The problem is selecting the -one that best solves the problems that their applications face. -<table><tr><td><br></td><td width="1%"><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/intro/terrain.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> diff --git a/bdb/docs/ref/intro/dbis.html b/bdb/docs/ref/intro/dbis.html deleted file mode 100644 index 10c4abd9585..00000000000 --- a/bdb/docs/ref/intro/dbis.html +++ /dev/null @@ -1,159 +0,0 @@ -<!--$Id: dbis.so,v 10.5 2001/01/19 17:30:29 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?</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/terrain.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/dbisnot.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>What is Berkeley DB?</h1> -<p>So far, we've discussed database systems in general terms. It's time -now to consider Berkeley DB in particular and see how it fits into the -framework we have introduced. The key question is, what kinds of -applications should use Berkeley DB? -<p>Berkeley DB is an open source embedded database library that provides -scalable, high-performance, transaction-protected data management -services to applications. Berkeley DB provides a simple function-call API -for data access and management. -<p>By "open source," we mean that Berkeley DB is distributed under a license that -conforms to the <a href="http://www.opensource.org/osd.html">Open -Source Definition</a>. This license guarantees that Berkeley DB is freely -available for use and redistribution in other open source products. -<a href="http://www.sleepycat.com">Sleepycat Software</a> sells -commercial licenses for redistribution in proprietary applications, but -in all cases the complete source code for Berkeley DB is freely available for -download and use. -<p>Berkeley DB is embedded because it links directly into the application. It -runs in the same address space as the application. As a result, no -inter-process communication, either over the network or between -processes on the same machine, is required for database operations. -Berkeley DB provides a simple function-call API for a number of programming -languages, including C, C++, Java, Perl, Tcl, Python, and PHP. All -database operations happen inside the library. Multiple processes, or -multiple threads in a single process, can all use the database at the -same time as each uses the Berkeley DB library. Low-level services like -locking, transaction logging, shared buffer management, memory -management, and so on are all handled transparently by the library. -<p>The library is extremely portable. It runs under almost all UNIX and -Linux variants, Windows, and a number of embedded real-time operating -systems. It runs on both 32-bit and 64-bit systems. -It has been deployed on high-end -Internet servers, desktop machines, and on palmtop computers, set-top -boxes, in network switches, and elsewhere. Once Berkeley DB is linked into -the application, the end user generally does not know that there's a -database present at all. -<p>Berkeley DB is scalable in a number of respects. The database library itself -is quite compact (under 300 kilobytes of text space on common -architectures), but it can manage databases up to 256 terabytes in size. -It also supports high concurrency, with thousands of users operating on -the same database at the same time. Berkeley DB is small enough to run in -tightly constrained embedded systems, but can take advantage of -gigabytes of memory and terabytes of disk on high-end server machines. -<p>Berkeley DB generally outperforms relational and object-oriented database -systems in embedded applications for a couple of reasons. First, because -the library runs in the same address space, no inter-process -communication is required for database operations. The cost of -communicating between processes on a single machine, or among machines -on a network, is much higher than the cost of making a function call. -Second, because Berkeley DB uses a simple function-call interface for all -operations, there is no query language to parse, and no execution plan -to produce. -<h3>Data Access Services</h3> -<p>Berkeley DB applications can choose the storage structure that best suits the -application. Berkeley DB supports hash tables, B-trees, simple -record-number-based storage, and persistent queues. Programmers can -create tables using any of these storage structures, and can mix -operations on different kinds of tables in a single application. -<p>Hash tables are generally good for very large databases that need -predictable search and update times for random-access records. Hash -tables allow users to ask, "Does this key exist?" or to fetch a record -with a known key. Hash tables do not allow users to ask for records -with keys that are close to a known key. -<p>B-trees are better for range-based searches, as when the application -needs to find all records with keys between some starting and ending -value. B-trees also do a better job of exploiting <i>locality -of reference</i>. If the application is likely to touch keys near each -other at the same time, the B-trees work well. The tree structure keeps -keys that are close together near one another in storage, so fetching -nearby values usually doesn't require a disk access. -<p>Record-number-based storage is natural for applications that need -to store and fetch records, but that do not have a simple way to -generate keys of their own. In a record number table, the record -number is the key for the record. Berkeley DB will can generate these -record numbers automatically. -<p>Queues are well-suited for applications that create records, and then -must deal with those records in creation order. A good example is -on-line purchasing systems. Orders can enter the system at any time, -but should generally be filled in the order in which they were placed. -<h3>Data management services</h3> -<p>Berkeley DB offers important data management services, including concurrency, -transactions, and recovery. All of these services work on all of the -storage structures. -<p>Many users can work on the same database concurrently. Berkeley DB handles -locking transparently, ensuring that two users working on the same -record do not interfere with one another. -<p>The library provides strict ACID transaction semantics. Some systems -allow the user to relax, for example, the isolation guarantees that the -database system makes. Berkeley DB ensures that all applications can see only -committed updates. -<p>Multiple operations can be grouped into a single transaction, and can -be committed or rolled back atomically. Berkeley DB uses a technique called -<i>two-phase locking</i> to be sure that concurrent transactions -are isolated from one another, and a technique called -<i>write-ahead logging</i> to guarantee that committed changes -survive application, system, or hardware failures. -<p>When an application starts up, it can ask Berkeley DB to run recovery. -Recovery restores the database to a clean state, with all committed -changes present, even after a crash. The database is guaranteed to be -consistent and all committed changes are guaranteed to be present when -recovery completes. -<p>An application can specify, when it starts up, which data management -services it will use. Some applications need fast, -single-user, non-transactional B-tree data storage. In that case, the -application can disable the locking and transaction systems, and will -not incur the overhead of locking or logging. If an application needs -to support multiple concurrent users, but doesn't need transactions, it -can turn on locking without transactions. Applications that need -concurrent, transaction-protected database access can enable all of the -subsystems. -<p>In all these cases, the application uses the same function-call API to -fetch and update records. -<h3>Design</h3> -<p>Berkeley DB was designed to provide industrial-strength database services to -application developers, without requiring them to become database -experts. It is a classic C-library style <i>toolkit</i>, providing -a broad base of functionality to application writers. Berkeley DB was designed -by programmers, for programmers: its modular design surfaces simple, -orthogonal interfaces to core services, and it provides mechanism (for -example, good thread support) without imposing policy (for example, the -use of threads is not required). Just as importantly, Berkeley DB allows -developers to balance performance against the need for crash recovery -and concurrent use. An application can use the storage structure that -provides the fastest access to its data and can request only the degree -of logging and locking that it needs. -<p>Because of the tool-based approach and separate interfaces for each -Berkeley DB subsystem, you can support a complete transaction environment for -other system operations. Berkeley DB even allows you to wrap transactions -around the standard UNIX file read and write operations! Further, Berkeley DB -was designed to interact correctly with the native system's toolset, a -feature no other database package offers. For example, Berkeley DB supports -hot backups (database backups while the database is in use), using -standard UNIX system utilities, e.g., dump, tar, cpio, pax or even cp. -<p>Finally, because scripting language interfaces are available for Berkeley DB -(notably Tcl and Perl), application writers can build incredibly powerful -database engines with little effort. You can build transaction-protected -database applications using your favorite scripting languages, an -increasingly important feature in a world using CGI scripts to deliver -HTML. -<table><tr><td><br></td><td width="1%"><a href="../../ref/intro/terrain.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/dbisnot.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> diff --git a/bdb/docs/ref/intro/dbisnot.html b/bdb/docs/ref/intro/dbisnot.html deleted file mode 100644 index a55fa71763e..00000000000 --- a/bdb/docs/ref/intro/dbisnot.html +++ /dev/null @@ -1,146 +0,0 @@ -<!--$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> diff --git a/bdb/docs/ref/intro/distrib.html b/bdb/docs/ref/intro/distrib.html deleted file mode 100644 index a5ff52263c2..00000000000 --- a/bdb/docs/ref/intro/distrib.html +++ /dev/null @@ -1,28 +0,0 @@ -<!--$Id: distrib.so,v 10.16 2000/09/22 18:23:58 bostic Exp $--> -<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.--> -<!--All rights reserved.--> -<html> -<head> -<title>Berkeley DB Reference Guide: What does the Berkeley DB distribution include?</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/what.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/where.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>What does the Berkeley DB distribution include?</h1> -<p>The Berkeley DB distribution includes complete source code for the Berkeley DB -library, including all three Berkeley DB products and their supporting -utilities, as well as complete documentation in HTML format. -<p>The distribution does not include pre-built binaries or libraries, or -hard-copy documentation. Pre-built libraries and binaries for some -architecture/compiler combinations are available as part of Sleepycat -Software's Berkeley DB support services. -<table><tr><td><br></td><td width="1%"><a href="../../ref/intro/what.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/where.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> diff --git a/bdb/docs/ref/intro/need.html b/bdb/docs/ref/intro/need.html deleted file mode 100644 index 771dd98908c..00000000000 --- a/bdb/docs/ref/intro/need.html +++ /dev/null @@ -1,60 +0,0 @@ -<!--$Id: need.so,v 10.2 2000/12/08 23:59:06 mao Exp $--> -<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.--> -<!--All rights reserved.--> -<html> -<head> -<title>Berkeley DB Reference Guide: Do you need Berkeley DB?</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/dbisnot.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/what.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>Do you need Berkeley DB?</h1> -<p>Berkeley DB is an ideal database system for applications that need fast, -scalable, and reliable embedded database management. For applications -that need different services, however, it can be a poor choice. -<p>First, do you need the ability to access your data in ways you cannot -predict in advance? If your users want to be able to enter SQL -queries to perform -complicated searches that you cannot program into your application to -begin with, then you should consider a relational engine instead. Berkeley DB -requires a programmer to write code in order to run a new kind of query. -<p>On the other hand, if you can predict your data access patterns up front --- and in particular if you need fairly simple key/value lookups -- then -Berkeley DB is a good choice. The queries can be coded up once, and will then -run very quickly because there is no SQL to parse and execute. -<p>Second, are there political arguments for or against a standalone -relational server? If you're building an application for your own use -and have a relational system installed with administrative support -already, it may be simpler to use that than to build and learn Berkeley DB. -On the other hand, if you'll be shipping many copies of your application -to customers, and don't want your customers to have to buy, install, -and manage a separate database system, then Berkeley DB may be a better -choice. -<p>Third, are there any technical advantages to an embedded database? If -you're building an application that will run unattended for long periods -of time, or for end users who are not sophisticated administrators, then -a separate server process may be too big a burden. It will require -separate installation and management, and if it creates new ways for -the application to fail, or new complexities to master in the field, -then Berkeley DB may be a better choice. -<p>The fundamental question is, how closely do your requirements match the -Berkeley DB design? Berkeley DB was conceived and built to provide fast, reliable, -transaction-protected record storage. The library itself was never -intended to provide interactive query support, graphical reporting -tools, or similar services that some other database systems provide. We -have tried always to err on the side of minimalism and simplicity. By -keeping the library small and simple, we create fewer opportunities for -bugs to creep in, and we guarantee that the database system stays fast, -because there is very little code to execute. If your application needs -that set of features, then Berkeley DB is almost certainly the best choice -for you. -<table><tr><td><br></td><td width="1%"><a href="../../ref/intro/dbisnot.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/what.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> diff --git a/bdb/docs/ref/intro/products.html b/bdb/docs/ref/intro/products.html deleted file mode 100644 index ce04135f03a..00000000000 --- a/bdb/docs/ref/intro/products.html +++ /dev/null @@ -1,69 +0,0 @@ -<!--$Id: products.so,v 10.13 2000/12/04 18:05:42 bostic Exp $--> -<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.--> -<!--All rights reserved.--> -<html> -<head> -<title>Berkeley DB Reference Guide: Sleepycat Software's Berkeley DB products</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> - <a name="2"><!--meow--></a> -<table><tr valign=top> -<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Introduction</dl></h3></td> -<td width="1%"><a href="../../ref/intro/where.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/simple_tut/intro.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>Sleepycat Software's Berkeley DB products</h1> -<p>Sleepycat Software licenses three different products that use the Berkeley DB -technology. Each product offers a distinct level of database support. -It is not possible to mix-and-match products, that is, each application -or group of applications must use the same Berkeley DB product. -<p>All three products are included in the single Open Source distribution of -Berkeley DB from Sleepycat Software, and building that distribution -automatically builds all three products. Each product adds services, and -new interfaces, to the product that precedes it in the list. As a result, -developers can download Berkeley DB and build an application that does only -single-user, read-only database access, and later add support for more -users and more complex database access patterns. -<p>Users who distribute Berkeley DB must ensure that they are licensed for the -Berkeley DB interfaces they use. Information on licensing is available directly -from Sleepycat Software. -<h3>Berkeley DB Data Store</h3> -<p>The Berkeley DB Data Store product is an embeddable, high-performance data store. It -supports multiple concurrent threads of control to read information -managed by Berkeley DB. When updates are required, only a single process may -be using the database. That process may be multi-threaded, but only one -thread of control should be allowed to update the database at any time. -The Berkeley DB Data Store does no locking, and so provides no guarantees of correct -behavior if more than one thread of control is updating the database at -a time. -<p>The Berkeley DB Data Store product includes the <a href="../../api_c/db_create.html">db_create</a> interface, the -DB handle methods, and the methods returned by <a href="../../api_c/db_cursor.html">DB->cursor</a>. -<p>The Berkeley DB Data Store is intended for use in single-user or read-only applications -that can guarantee that no more than one thread of control will ever -update the database at any time. -<h3>Berkeley DB Concurrent Data Store</h3> -<p>The Berkeley DB Concurrent Data Store product adds multiple-reader, single writer capabilities to -the Berkeley DB Data Store product, supporting applications that need concurrent updates -and do not want to implement their own locking protocols. The additional -interfaces included with the Berkeley DB Concurrent Data Store product are <a href="../../api_c/env_create.html">db_env_create</a>, the -<a href="../../api_c/env_open.html">DBENV->open</a> method (using the <a href="../../api_c/env_open.html#DB_INIT_CDB">DB_INIT_CDB</a> flag), and the -<a href="../../api_c/env_close.html">DBENV->close</a> method. -<p>Berkeley DB Concurrent Data Store is intended for applications that require occasional write access -to a database that is largely used for reading. -<h3>Berkeley DB Transactional Data Store</h3> -<p>The Berkeley DB Transactional Data Store product adds full transactional support and recoverability -to the Berkeley DB Data Store product. This product includes all of the interfaces -in the Berkeley DB library. -<p>Berkeley DB Transactional Data Store is intended for applications that require industrial-strength -database services, including good performance under high-concurrency -workloads with a mixture of readers and writers, the ability to commit -or roll back multiple changes to the database at a single instant, and -the guarantee that even in the event of a catastrophic system or hardware -failure, any committed database changes will be preserved. -<table><tr><td><br></td><td width="1%"><a href="../../ref/intro/where.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/simple_tut/intro.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> diff --git a/bdb/docs/ref/intro/terrain.html b/bdb/docs/ref/intro/terrain.html deleted file mode 100644 index f2a7089135c..00000000000 --- a/bdb/docs/ref/intro/terrain.html +++ /dev/null @@ -1,248 +0,0 @@ -<!--$Id: terrain.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: Mapping the terrain: theory and practice</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/data.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/dbis.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>Mapping the terrain: theory and practice</h1> -<p>The first step in selecting a database system is figuring out what the -choices are. Decades of research and real-world deployment have produced -countless systems. We need to organize them somehow to reduce the number -of options. -<p>One obvious way to group systems is to use the common labels that -vendors apply to them. The buzzwords here include "network," -"relational," "object-oriented," and "embedded," with some -cross-fertilization like "object-relational" and "embedded network". -Understanding the buzzwords is important. Each has some grounding in -theory, but has also evolved into a practical label for categorizing -systems that work in a certain way. -<p>All database systems, regardless of the buzzwords that apply to them, -provide a few common services. All of them store data, for example. -We'll begin by exploring the common services that all systems provide, -and then examine the differences among the different kinds of systems. -<h3>Data access and data management</h3> -<p>Fundamentally, database systems provide two services. -<p>The first service is <i>data access</i>. Data access means adding -new data to the database (inserting), finding data of interest -(searching), changing data already stored (updating), and removing data -from the database (deleting). All databases provide these services. How -they work varies from category to category, and depends on the record -structure that the database supports. -<p>Each record in a database is a collection of values. For example, the -record for a Web site customer might include a name, email address, -shipping address, and payment information. Records are usually stored -in tables. Each table holds records of the same kind. For example, the -<b>customer</b> table at an e-commerce Web site might store the -customer records for every person who shopped at the site. Often, -database records have a different structure from the structures or -instances supported by the programming language in which an application -is written. As a result, working with records can mean: -<ul type=disc> -<li>using database operations like searches and updates on records; and -<li>converting between programming language structures and database record -types in the application. -</ul> -<p>The second service is <i>data management</i>. Data management is -more complicated than data access. Providing good data management -services is the hard part of building a database system. When you -choose a database system to use in an application you build, making sure -it supports the data management services you need is critical. -<p>Data management services include allowing multiple users to work on the -database simultaneously (concurrency), allowing multiple records to be -changed instantaneously (transactions), and surviving application and -system crashes (recovery). Different database systems offer different -data management services. Data management services are entirely -independent of the data access services listed above. For example, -nothing about relational database theory requires that the system -support transactions, but most commercial relational systems do. -<p>Concurrency means that multiple users can operate on the database at -the same time. Support for concurrency ranges from none (single-user -access only) to complete (many readers and writers working -simultaneously). -<p>Transactions permit users to make multiple changes appear at once. For -example, a transfer of funds between bank accounts needs to be a -transaction because the balance in one account is reduced and the -balance in the other increases. If the reduction happened before the -increase, than a poorly-timed system crash could leave the customer -poorer; if the bank used the opposite order, then the same system crash -could make the customer richer. Obviously, both the customer and the -bank are best served if both operations happen at the same instant. -<p>Transactions have well-defined properties in database systems. They are -<i>atomic</i>, so that the changes happen all at once or not at all. -They are <i>consistent</i>, so that the database is in a legal state -when the transaction begins and when it ends. They are typically -<i>isolated</i>, which means that any other users in the database -cannot interfere with them while they are in progress. And they are -<i>durable</i>, so that if the system or application crashes after -a transaction finishes, the changes are not lost. Together, the -properties of <i>atomicity</i>, <i>consistency</i>, -<i>isolation</i>, and <i>durability</i> are known as the ACID -properties. -<p>As is the case for concurrency, support for transactions varies among -databases. Some offer atomicity without making guarantees about -durability. Some ignore isolatability, especially in single-user -systems; there's no need to isolate other users from the effects of -changes when there are no other users. -<p>Another important data management service is recovery. Strictly -speaking, recovery is a procedure that the system carries out when it -starts up. The purpose of recovery is to guarantee that the database is -complete and usable. This is most important after a system or -application crash, when the database may have been damaged. The recovery -process guarantees that the internal structure of the database is good. -Recovery usually means that any completed transactions are checked, and -any lost changes are reapplied to the database. At the end of the -recovery process, applications can use the database as if there had been -no interruption in service. -<p>Finally, there are a number of data management services that permit -copying of data. For example, most database systems are able to import -data from other sources, and to export it for use elsewhere. Also, most -systems provide some way to back up databases and to restore in the -event of a system failure that damages the database. Many commercial -systems allow <i>hot backups</i>, so that users can back up -databases while they are in use. Many applications must run without -interruption, and cannot be shut down for backups. -<p>A particular database system may provide other data management services. -Some provide browsers that show database structure and contents. Some -include tools that enforce data integrity rules, such as the rule that -no employee can have a negative salary. These data management services -are not common to all systems, however. Concurrency, recovery, and -transactions are the data management services that most database vendors -support. -<p>Deciding what kind of database to use means understanding the data -access and data management services that your application needs. Berkeley DB -is an embedded database that supports fairly simple data access with a -rich set of data management services. To highlight its strengths and -weaknesses, we can compare it to other database system categories. -<h3>Relational databases</h3> -<p>Relational databases are probably the best-known database variant, -because of the success of companies like Oracle. Relational databases -are based on the mathematical field of set theory. The term "relation" -is really just a synonym for "set" -- a relation is just a set of -records or, in our terminology, a table. One of the main innovations in -early relational systems was to insulate the programmer from the -physical organization of the database. Rather than walking through -arrays of records or traversing pointers, programmers make statements -about tables in a high-level language, and the system executes those -statements. -<p>Relational databases operate on <i>tuples</i>, or records, composed -of values of several different data types, including integers, character -strings, and others. Operations include searching for records whose -values satisfy some criteria, updating records, and so on. -<p>Virtually all relational databases use the Structured Query Language, -or SQL. This language permits people and computer programs to work with -the database by writing simple statements. The database engine reads -those statements and determines how to satisfy them on the tables in -the database. -<p>SQL is the main practical advantage of relational database systems. -Rather than writing a computer program to find records of interest, the -relational system user can just type a query in a simple syntax, and -let the engine do the work. This gives users enormous flexibility; they -do not need to decide in advance what kind of searches they want to do, -and they do not need expensive programmers to find the data they need. -Learning SQL requires some effort, but it's much simpler than a -full-blown high-level programming language for most purposes. And there -are a lot of programmers who have already learned SQL. -<h3>Object-oriented databases</h3> -<p>Object-oriented databases are less common than relational systems, but -are still fairly widespread. Most object-oriented databases were -originally conceived as persistent storage systems closely wedded to -particular high-level programming languages like C++. With the spread -of Java, most now support more than one programming language, but -object-oriented database systems fundamentally provide the same class -and method abstractions as do object-oriented programming languages. -<p>Many object-oriented systems allow applications to operate on objects -uniformly, whether they are in memory or on disk. These systems create -the illusion that all objects are in memory all the time. The advantage -to object-oriented programmers who simply want object storage and -retrieval is clear. They need never be aware of whether an object is in -memory or not. The application simply uses objects, and the database -system moves them between disk and memory transparently. All of the -operations on an object, and all its behavior, are determined by the -programming language. -<p>Object-oriented databases aren't nearly as widely deployed as relational -systems. In order to attract developers who understand relational -systems, many of the object-oriented systems have added support for -query languages very much like SQL. In practice, though, object-oriented -databases are mostly used for persistent storage of objects in C++ and -Java programs. -<h3>Network databases</h3> -<p>The "network model" is a fairly old technique for managing and -navigating application data. Network databases are designed to make -pointer traversal very fast. Every record stored in a network database -is allowed to contain pointers to other records. These pointers are -generally physical addresses, so fetching the referenced record just -means reading it from disk by its disk address. -<p>Network database systems generally permit records to contain integers, -floating point numbers, and character strings, as well as references to -other records. An application can search for records of interest. After -retrieving a record, the application can fetch any referenced record -quickly. -<p>Pointer traversal is fast because most network systems use physical disk -addresses as pointers. When the application wants to fetch a record, -the database system uses the address to fetch exactly the right string -of bytes from the disk. This requires only a single disk access in all -cases. Other systems, by contrast, often must do more than one disk read -to find a particular record. -<p>The key advantage of the network model is also its main drawback. The -fact that pointer traversal is so fast means that applications that do -it will run well. On the other hand, storing pointers all over the -database makes it very hard to reorganize the database. In effect, once -you store a pointer to a record, it is difficult to move that record -elsewhere. Some network databases handle this by leaving forwarding -pointers behind, but this defeats the speed advantage of doing a single -disk access in the first place. Other network databases find, and fix, -all the pointers to a record when it moves, but this makes -reorganization very expensive. Reorganization is often necessary in -databases, since adding and deleting records over time will consume -space that cannot be reclaimed without reorganizing. Without periodic -reorganization to compact network databases, they can end up with a -considerable amount of wasted space. -<h3>Clients and servers</h3> -<p>Database vendors have two choices for system architecture. They can -build a server to which remote clients connect, and do all the database -management inside the server. Alternatively, they can provide a module -that links directly into the application, and does all database -management locally. In either case, the application developer needs -some way of communicating with the database (generally, an Application -Programming Interface (API) that does work in the process or that -communicates with a server to get work done). -<p>Almost all commercial database products are implemented as servers, and -applications connect to them as clients. Servers have several features -that make them attractive. -<p>First, because all of the data is managed by a separate process, and -possibly on a separate machine, it's easy to isolate the database server -from bugs and crashes in the application. -<p>Second, because some database products (particularly relational engines) -are quite large, splitting them off as separate server processes keeps -applications small, which uses less disk space and memory. Relational -engines include code to parse SQL statements, to analyze them and -produce plans for execution, to optimize the plans, and to execute -them. -<p>Finally, by storing all the data in one place and managing it with a -single server, it's easier for organizations to back up, protect, and -set policies on their databases. The enterprise databases for large -companies often have several full-time administrators caring for them, -making certain that applications run quickly, granting and denying -access to users, and making backups. -<p>However, centralized administration can be a disadvantage in some cases. -In particular, if a programmer wants to build an application that uses -a database for storage of important information, then shipping and -supporting the application is much harder. The end user needs to install -and administer a separate database server, and the programmer must -support not just one product, but two. Adding a server process to the -application creates new opportunity for installation mistakes and -run-time problems. -<table><tr><td><br></td><td width="1%"><a href="../../ref/intro/data.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/dbis.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> diff --git a/bdb/docs/ref/intro/what.html b/bdb/docs/ref/intro/what.html deleted file mode 100644 index c8d12069a57..00000000000 --- a/bdb/docs/ref/intro/what.html +++ /dev/null @@ -1,53 +0,0 @@ -<!--$Id: what.so,v 10.22 2000/09/22 18:23:59 bostic Exp $--> -<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.--> -<!--All rights reserved.--> -<html> -<head> -<title>Berkeley DB Reference Guide: What other services does Berkeley DB provide?</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/need.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/distrib.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>What other services does Berkeley DB provide?</h1> -<p>Berkeley DB also provides core database services to developers. These -services include: -<p><dl compact> -<p><dt>Page cache management:<dd>The page cache provides fast access to a cache of database pages, -handling the I/O associated with the cache to ensure that dirty pages -are written back to the file system and that new pages are allocated on -demand. Applications may use the Berkeley DB shared memory buffer manager to -serve their own files and pages. -<p><dt>Transactions and logging:<dd>The transaction and logging systems provide recoverability and atomicity -for multiple database operations. The transaction system uses two-phase -locking and write-ahead logging protocols to ensure that database -operations may be undone or redone in the case of application or system -failure. Applications may use Berkeley DB transaction and logging subsystems -to protect their own data structures and operations from application or -system failure. -<p><dt>Locking:<dd>The locking system provides multiple reader or single writer access to -objects. The Berkeley DB access methods use the locking system to acquire -the right to read or write database pages. Applications may use the -Berkeley DB locking subsystem to support their own locking needs. -</dl> -<p>By combining the page cache, transaction, locking, and logging systems, -Berkeley DB provides the same services found in much larger, more complex and -more expensive database systems. Berkeley DB supports multiple simultaneous -readers and writers and guarantees that all changes are recoverable, even -in the case of a catastrophic hardware failure during a database update. -<p>Developers may select some or all of the core database services for any -access method or database. Therefore, it is possible to choose the -appropriate storage structure and the right degrees of concurrency and -recoverability for any application. In addition, some of the systems -(e.g., the locking subsystem) can be called separately from the Berkeley DB -access method. As a result, developers can integrate non-database -objects into their transactional applications using Berkeley DB. -<table><tr><td><br></td><td width="1%"><a href="../../ref/intro/need.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/distrib.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> diff --git a/bdb/docs/ref/intro/where.html b/bdb/docs/ref/intro/where.html deleted file mode 100644 index 45d0dc3ae99..00000000000 --- a/bdb/docs/ref/intro/where.html +++ /dev/null @@ -1,39 +0,0 @@ -<!--$Id: where.so,v 10.27 2000/12/04 18:05:42 bostic Exp $--> -<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.--> -<!--All rights reserved.--> -<html> -<head> -<title>Berkeley DB Reference Guide: Where does Berkeley DB run?</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/distrib.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/products.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>Where does Berkeley DB run?</h1> -<p>Berkeley DB requires only underlying IEEE/ANSI Std 1003.1 (POSIX) system calls and can be -ported easily to new architectures by adding stub routines to connect -the native system interfaces to the Berkeley DB POSIX-style system calls. -<p>Berkeley DB will autoconfigure and run on almost any modern UNIX system, and -even on most historical UNIX platforms. See -<a href="../../ref/build_unix/intro.html">Building for UNIX systems</a> for -more information. -<p>The Berkeley DB distribution includes support for QNX Neutrino. See -<a href="../../ref/build_unix/intro.html">Building for UNIX systems</a> for -more information. -<p>The Berkeley DB distribution includes support for VxWorks, via a workspace -and project files for Tornado 2.0. See -<a href="../../ref/build_vxworks/intro.html">Building for VxWorks</a> for more -information. -<p>The Berkeley DB distribution includes support for Windows/95, Windows/98, -Windows/NT and Windows/2000, via the MSVC 5 and 6 development -environments. See <a href="../../ref/build_win/intro.html">Building for -Windows systems</a> for more information. -<table><tr><td><br></td><td width="1%"><a href="../../ref/intro/distrib.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/products.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> |