NexusDB

NexusDB has been fundamentally designed with a Client/Server architecture.  It has three distinct layers: client, server and remoting.  Each layer has specific responsibilities within this architecture. The Client layer provides high level data access capabilities. The Server layer stores and retrieves data and the Remoting layer connects the Client layer with the Server layer. The overall architecture looks like this:

It is important to note that even as an embedded database, NexusDB preserves the client/server architecture; the only difference is the absence of the Remoting layer. This architecture thus reduces to:

The client layer provides standard TDataSet descendants that are used to build native or web based user interfaces.  This layer is easy to use and follows the traditional Borland data access paradigm.  The client communicates through a well-defined interface with a server instance.

The remoting layer is responsible for connecting the client layer to the server.  It does so through various network protocols: TCP/IP, named pipes, Shared Memory or COM.  It also supports encryption and compression through each of these protocols.  NexusDB is completely extensible and can support any additional protocol.

If the client and server run within the same process the remoting layer is not necessary.  Embedding the server within the client process is one of the flexible deployment options NexusDB supports.  Deployment options are discussed in depth later in this section.

The server layer is the core database engine and is the only layer that directly interacts with the data files.  Concurrency control, transaction management and data caching services are efficiently implemented within the server layer.  The server layer supports ANSI standard SQL and can be accessed via ODBC or dbExpress APIs.

It is important to contrast NexusDB's client/server architecture with databases that use file-based architectures.  In a file-based architecture, there is no separation of client and server, thus each client directly manipulates the data files.  There are significant differences in the following areas: concurrency locking mechanisms, caching capabilities, and scalability.

Most database engines that are file-based use file locking through a file system API (e.g. Windows LockFile).  These locks are called virtual byte locks; this means that they lock portions of a file that do not physically exist.  Each client respects these locks when reading or writing to a particular table.

File-based databases suffer from scalability bottlenecks because of many factors.  Network traffic is increased because each client must retrieve the entire files contents because there is no server process to apply the selection criteria.  Disk caching of data blocks is not possible because there is no way for each individual client to keep track of data that has changed since the last read.  External file locks are much slower than their Client/Server counterparts: in-process synchronization primitives.

The following diagram illustrates the differences: