Christopher Browne <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
>
> It also seems quite curious why in-process embedding should be so
> attractive;
>
People seem not to care whether or not the RDBMS runs in-process or
in a separately forked process. The attribute that concerns them
is that the RDBMS is requires zero configuration. There is no separate
server process to install, configure, initialize, and administer. An
application using a zero-configuration database engine just works.
No need to run a setup wizard to get it going. No need to pester
your system administrator to create a new user on the database server.
Just copy over the executable, run it, and it works.
Another way to think about it is that an embedded RDBMS is not necessarily
a replacement for a traditional client/server database, but rather a
replacement for fopen() and friends accessing an ad hoc text file. Using
an embedded database is better than fopen() in that it provides a
schema layer and ACID transactions.
There are many applications for which the traditional client/server
database architecture with the server running in a separate process
is definately the best approach. But there are just as many other
uses for which an embedded database engine works best. For example,
an embedded database engine which stores the database in a single
orginary disk file can be used as an application file format.
The File/Open menu option creates a connection to the database file.
File/Save commits the changes. The application reads and writes
using ordinary SQL. Afterwards, the user can email the resulting
database to a friend. Client/server database engines will not
easily do this kind of stuff.
Client/server database engines clearly have their place. But they
are not always the best solution to every data storage problem.
Expand your horizons.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
