1<!--$Id: need.so,v 10.2 2000/12/08 23:59:06 mao Exp $--> 2<!--Copyright (c) 1997,2008 Oracle. All rights reserved.--> 3<!--See the file LICENSE for redistribution information.--> 4<html> 5<head> 6<title>Berkeley DB Reference Guide: Do you need Berkeley DB?</title> 7<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> 8<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++"> 9</head> 10<body bgcolor=white> 11<table width="100%"><tr valign=top> 12<td><b><dl><dt>Berkeley DB Reference Guide:<dd>Introduction</dl></b></td> 13<td align=right><a href="../intro/dbisnot.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../intro/what.html"><img src="../../images/next.gif" alt="Next"></a> 14</td></tr></table> 15<p align=center><b>Do you need Berkeley DB?</b></p> 16<p>Berkeley DB is an ideal database system for applications that need fast, 17scalable, and reliable embedded database management. For applications 18that need different services, however, it can be a poor choice.</p> 19<p>First, do you need the ability to access your data in ways you cannot 20predict in advance? If your users want to be able to enter SQL 21queries to perform 22complicated searches that you cannot program into your application to 23begin with, then you should consider a relational engine instead. Berkeley DB 24requires a programmer to write code in order to run a new kind of query.</p> 25<p>On the other hand, if you can predict your data access patterns up front 26-- and in particular if you need fairly simple key/value lookups -- then 27Berkeley DB is a good choice. The queries can be coded up once, and will then 28run very quickly because there is no SQL to parse and execute.</p> 29<p>Second, are there political arguments for or against a standalone 30relational server? If you're building an application for your own use 31and have a relational system installed with administrative support 32already, it may be simpler to use that than to build and learn Berkeley DB. 33On the other hand, if you'll be shipping many copies of your application 34to customers, and don't want your customers to have to buy, install, 35and manage a separate database system, then Berkeley DB may be a better 36choice.</p> 37<p>Third, are there any technical advantages to an embedded database? If 38you're building an application that will run unattended for long periods 39of time, or for end users who are not sophisticated administrators, then 40a separate server process may be too big a burden. It will require 41separate installation and management, and if it creates new ways for 42the application to fail, or new complexities to master in the field, 43then Berkeley DB may be a better choice.</p> 44<p>The fundamental question is, how closely do your requirements match the 45Berkeley DB design? Berkeley DB was conceived and built to provide fast, reliable, 46transaction-protected record storage. The library itself was never 47intended to provide interactive query support, graphical reporting 48tools, or similar services that some other database systems provide. We 49have tried always to err on the side of minimalism and simplicity. By 50keeping the library small and simple, we create fewer opportunities for 51bugs to creep in, and we guarantee that the database system stays fast, 52because there is very little code to execute. If your application needs 53that set of features, then Berkeley DB is almost certainly the best choice 54for you.</p> 55<table width="100%"><tr><td><br></td><td align=right><a href="../intro/dbisnot.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../intro/what.html"><img src="../../images/next.gif" alt="Next"></a> 56</td></tr></table> 57<p><font size=1>Copyright (c) 1996,2008 Oracle. All rights reserved.</font> 58</body> 59</html> 60
