Programming with Lava Distributed SQL

Programming considerations revolve around two major aspects. The first is the programming language chosen, the second being programming aspects unique to Lava Distributed SQL or dif fering from similar functionality in conventional databases.

Supported Programming Languages

Full support for these languages is provided either within the Blueprint Development Environment or in conjunction with alternate development packages :

• LavaStream

LavaStream is fully and tightly integrated with Lava Distributed SQL, and includes specific commands and functions which provide direct and comprehensive access to all facilities available. LavaStream is directly supported by Blueprint.

• Oberon

Oberon has a comprehensive set of definitions, constants and facilities which provide a complete interface to Distributed SQL. Oberon is directly supported by Blueprint.

• "C", C++

A fairly comprehensive set of definitions and constants are provided which allow both languages to interface to the Lava system to a good degree. At the current time there is only limited support within Blueprint for compilation, and as a result an alternative environment (such as DotNet) must be used for this purpose. Work is in progress to integrate the Microsoft compiler into Blueprint, and we anticipate that relatively full support should be provided within the next 6 months.

Partly Supported Languages

The following languages are capable of interfacing to Lava Distributed SQL, in some cases with restricted facilities :

• Clarion

The Clarion language does not have all the facilities required to fully integrate with Lava Distributed SQL, but a relatively large subset of the interface can be specified and linked. At the current time, only a small part of the possible interfaces are supported, but this will be extended in time.

• Pascal

Although there is currently little specific support for Pascal, the language is capable of interfacing with the entire Lava system. There are no specific plans regarding Pascal, but if customer requirement arises appropriate interfaces may be generated.

• PHP

Preliminary testing has been done on relatively simple PHP examples, and no obvious problems were encountered. Extensive further testing will have to be undertaken before we can endorse PHP for larger more complex systems.

Unsupported Languages

Some popular languages are not supported, or are not capable of interfacing to the Lava system :

• C#

Nominally capable of interfacing, a significant amount of work would have to be undertaken to generate the interface structures and definitions. Due to the slightly inappropriate nature of the C# language, there is at this time no intention to provide an interface.

• Java

The Java language and environment has a number of problems which render interfacing troublesome. Java is quite slow and has significant memory complications. In addition, the purely object oriented nature of the language clashes with many of the fundamental interface approaches of the Lava system which is more procedural in nature.

• Visual Basic

In principle it would be possible to interface Visual Basic, but the potential benefit is small and several interface mechanisms cannot be supported due to inadequacies in the language.

Programming Aspects and Techniques

It is possible to interface to Distributed SQL in exactly the same way one would interface to Oracle or SQL Server, but this would be a very inefficient method. In order to derive the maximum benefit from the system, it is necessary to adopt a different approach. Some of the typical techniques are listed here.

• Use of SQL

Where SQL is appropriate, and presents a better option for retrieving data than row-level operations, this may be used freely - however, it is important to pay attention to where the SQL should be executed. In most cases, executing the SQL on the client is the fastest way to retrieve the information, as well as removing processing load from the server. In order to do this, all the tables involved in the query (or update) must be fully distributed to the client. Where this is not the case, the execution must be forced to the server.

• Row-level operations

In many cases, both from the point of view of ease of programming as well as that of efficiency, row-level operations (seek, get, put, delete) may be more effectively employed than SQL. This is especially the case where either the operation is so simple that one or two row operations are all that is required, or where the result set to be obtained and/or updated is so complex that constructing an SQL statement becomes difficult if not impossible. In both of these cases, the best alternative is to write the algorithm using row-level operations.

• Sequential processing

When sequential processing of bulk data is undertaken using conventional means, this usually implies the execution of a SQL query in order to retrieve the required row set, then looping through the result set one row at a time to process the data. It is much more efficient (in most cases) to simply access the underlying table data using direct row access - this typically involves constructing a seek request, then sequentially processing the rows returned by the seek until a limiting condition is reached. Where related data is required, this may also be retrieved using seek / read technique, looping where required. With the exception of row sets involving multiple relations or moderately complex filtering requirements, the row level approach will be easier to write and far quicker to execute.

• Array access

Where table data is to be processed in bulk, the Lava database renders it possible to access underlying (fully distributed) data using array processing. This can only be used to retrieve data - updates would be of a temporary nature only, lost on disconnect - but will allow processing of vast amounts of data at speeds up to 100 times that of conventional techniques.