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_need.html | |
| parent | 7a2660ba9cc2dc03a69ddfcfd95369395cc87444 (diff) | |
| download | berkeleydb-master.tar.gz | |
Diffstat (limited to 'docs/programmer_reference/intro_need.html')
| -rw-r--r-- | docs/programmer_reference/intro_need.html | 104 |
1 files changed, 61 insertions, 43 deletions
diff --git a/docs/programmer_reference/intro_need.html b/docs/programmer_reference/intro_need.html index ee00e244..80d2fd8a 100644 --- a/docs/programmer_reference/intro_need.html +++ b/docs/programmer_reference/intro_need.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_dbisnot.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_what.html">Next</a></td> </tr> </table> @@ -38,45 +36,65 @@ </div> </div> </div> - <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> - <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> - <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> - <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> - <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> - <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.</p> + <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> + <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> + <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> + <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> + <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> + <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. + </p> </div> <div class="navfooter"> <hr /> |