1. Offer ruby programmers a simple database supporting SQ L syntax on ruby objects


  1. Support SQ L syntax and functionality

  2. Written completely in Ruby

  3. Flexibility is to be maintained. That is, a minimal reduction in Ruby functionality

  4. Security and speed are to be considered after realisation of a working design

Introduction:(Top down)

There are a good many designs fulfilling the requirements above.

But, here we can investigate one design, only.

As such, it may be useful, to write a very short introduction giving the SL8 project view; thereby clarifying ideas, and consolidating opinion,

In the grand scheme of things, the invention of new 'structures-of-computer-organisation', and their programming interfaces is the ultimate goal.

The Relational Data Model and Object Orientation Model are great examples of 'structures-of-computer-organisation' that are as innovative as they have proven to be successful.

But they are very different things:

They are as different in their areas of application as they differ in grammar.

Both, excelling in different areas of computing and both having different working methods.

From the human point of view, their ideas are so different as to be nearly incompatible (We are required to put on our SQ L hat. Take it off, and then put on our Object Orientation hat. (Having two hats on at the same time looks silly)).

A marriage of these two concepts is at best going to be a bad compromise.

(As I have mentioned earlier, the correct answer is to create a new idea, embracing Object Orientation and the Relational Model; in some new and ground breaking form.

But such an all-embracing solution is beyond the scope of SL8 project; and me.

And so, the SL8 project has failed before it has even begun.

With that said, I believe that some useful, but limited, progress can be made.)


The manner in which information is organised has a profound impact on how easy it is to access and manage.

  1. The Relational Model organises data into collections of two-dimensional tables called 'relations'.

  2. The Object Model organises data and functionality into collections called 'classes' that model in terms of things found in the real world, thus aiding human understanding of complex issues.

  1. SQ L databases excel at managing large amounts of data over long periods of time. And retrieving data in a fast and accurate manner.

  2. Object Orientated languages, like Ruby excel, at flexible information organisation, description, and human computer interaction. And Ruby excels at data manipulation.

The challenge, to unify the benefits of these two models without impeding either part. The answer, to choose an optimal organisation of Ruby objects.

SL8 offers one possible design. (everyone is free to have a go at designing a better one)


SL8's design is a naive mapping, written in Ruby, from the Object Orientated Model to the Relational Model.

As follows:











  1. The class - table mapping is intuitive and requires little explanation.

  2. The object - row mapping follows naturally from the class – table mapping. And, occurs (in SL8) as primary key and Marshalled Ruby object pair, stored in a Bucket Headers array.

      This choice is central to the SL8 approach. It means that objects added must be modified and stored before being added to the database. Imposing a large overheads on INSERT and UPDATE, amongst others.

3. Attribute - column mapping requires the automated update of classes to offer attribute read and write accessors to attributes described in the SL8 database scheme. Indexing is supported only for attributes enrolled in the SL8 database scheme.

In other words, objects that wish to have the functionality of a SQ L database only need to enrol attributes to the database scheme (and give a class name for a class available to the Ruby environment).

(This loose coupling is hoped to keep 'coders objects' lean (they are not required to inherit a monumental SQ L object) and hence a smaller database.)

4. Metric – data-type mapping.

Since Ruby has no data-types, SL8 must support the data-types of SQ L and any other Ruby objects enrolled in the manner above.

Moreover, SL8 must be able to do the comparisons between different data- types in the SQ L language and Ruby objects.

(e.g. Find strings of characters that are LIKE “_bloggs%”

or compare numbers with <, >, &c. or BETWEEN.)

To emulate this SQ L functionality (but not limit Ruby coders objects to SQ L data-types) stored objects maybe required to give their metrics for each comparable attribute in the scheme.

Specifically, describing how two objects of a class can be compared in terms of the Ruby Comparable Module (so that SL8 may automatically include that module and overload '<=>' with the required metric).











Defaults to .kind_of?() but can be overloaded

LIKE functionality

It is beginning to be come clear that SL8's naïve mapping is occurring in a larger context.