Advantages of Distributed SQL

The most significant advantages fall into four major categories.

Advantages to the user

Responsiveness is vastly better than that for a conventional database - the majority of information is obtained directly from the client database, significantly quicker than fetching the data from a central server.

Several operations are independent of the server, which means that if the link to the server is down (for remote applications) it is possible to continue working.

Due to the automatic Groupware enabling of client applications (a side effect of the way that Distributed SQL works) every user has immediate access to and visibility on everything that every other user has done - without any special programming.

As the application is simpler to design and implement, the user is presented with a more reliable, less fault-ridden application. Due to simplicity of programming, the application is also more efficient.

Advantages to the programmer

Writing an application for a Distributed SQL database is exactly the same as a single user application - the programmer does not have to take any multi-user database considerations into account. This means that application design and implementation is easier, quicker, and also significantly less error-prone.

Performance considerations are far less of an issue. As most instructions are executed on the client database, the programmer does not have to take server demand or multi-user contention into account. Due to the efficiency of distributed database operation, the application still runs faster despite the programmer not having to optimize as much.

Due to the single-user nature of a Distributed SQL application, it is possible to use row-level operations (row insert, update, delete) where these are more efficient and easier to code than the equivalent SQL. This results in a more efficient application as well as simpler code.

Every application written on a Distributed SQL database platform is automatically a Groupware application - without the programmer having to do anything at all.

Due to the speed and efficiency of Distributed SQL coupled to the simplicity of implementation, many desirable but seemingly complex application options become feasible. For example, the implementation of a simple spreadsheet or project management matrix becomes almost trivial - by contrast, these would be extremely difficult on a conventional client-server database.

Advantages to the server

As most queries are processed by the client, processing load is significantly reduced. The server therefore has far greater reserves for processing peak demand or larger numbers of clients.

Due to reduced demand, the server is able to process distribution requirements very rapidly - this results in a distributed database network which is up to date at all times.

As a result of the independence and relative intelligence of a Distributed SQL client, it is possible for the client database to re-connect to the server if a connection is lost or the server should become unavailable (due to loss of power or hardware failure). As soon as the server becomes available again, the client database re-establishes the connection, and continues operating as if nothing had happened. As a result, server down-time becomes an obsolete problem.

Data Security

Conventional databases typically process requests for information (as opposed to data) from client applications. For example, when a client is constructing a report, it will request entire and coherent information from the server which comprises the complete reporting requirement. A report containing customer and sales information will often be retrieved from the server in a single SQL select command. This command is always plain text, providing a perfect "key" to the layout of the data returned from the server. Although the communication from the server may be encrypted, if this transmission is intercepted it is possible - after some processing - to derive the original information. This may only be a week later, but the information will probably still be valid and worthwhile.

In contrast - using a distributed client - reports of this nature are typically generated locally from the client database. Therefore, coherent data (joined between multiple data tables) is almost never transmitted from the server to the client. Rather, the initial distribution transmits raw table data. This is of course also encrypted, but once again it is possible to attempt decryption. However, decryption is far more difficult, as the data is not coherent ASCII text but incomprehensible and incoherent jumbles of text snippets, floating-point data, other binary fields and so on. There is no "key" to the layout of this data. Should someone actually succeed in decrypting the data (a rather unlikely outcome) they are still presented with the formidable task of figuring out how the data fits together. As this data is raw table data, and the table formats and divisions are not available, it is an unimaginably complex task to decipher the underlying information.

Furthermore, in contrast with a conventional client where confidential data is transmitted between server and client repeatedly on every client request, a distributed client receives bulk (raw) data only once - directly after connection. Subsequent to this, only small packets of raw row data are transmitted between server and client.

In essence, communication between server and distributed client is as secure as you can get.