'Gard' - Genuine Ada Relational Database, semi-proposal

'Gard' - Genuine Ada Relational Database, semi-proposal

[Wa Benzi]

SQL is a popular dead-end. People chose databases for reliability, ultimately. The following URL
leads you to a discussion about what is required for a genuinely relational database:
http://dbappbuilder.sourceforge.net/Rel.html#Architecture

Why not translate this genuine relational database into Ada and throw out SQL? 

The basic structure of a parser exists in Java. It shouldn't be that difficult to design and
impelment at least an equivalent to the teaching model discussed at the above URL. Beyond that, Ada
ought to give the opportunity to engineer it to a rock-solid high performance engine.

It could be packaged with AdaOS (at an early stage of development, I know, but still).

The advantages seem to me to be considerable. 

---
Sent from UnionMail Service  [http://mail.union.org.za]

'Gard' - Genuine Ada Relational Database, semi-proposal

[Wa Benzi]

Some suggestions made regarding the DB and file system extensions to the AdaOS project. I'd be
interested to know if there is any support in this forum for the idea of open relational database
and file system projects as described below:

I think it would be wise to start a separate project for 'Carrot', an Ada relational database.
Before coding, I think it would be useful to spec out a full design, in some detail. For an Ada
environment encryption would be an important topic - probably at a record level. Access rights and
security, boring as they are, are also important. If you have a distributed model then you don't
want a centralised locking mechanism - you want some kind of distributed locking, probably object
orientated lock requests at the record level - doing this with low overhead is an interesting
challenge - one well known solution is to never lock on reads, only on writes, and to assume that
all reads are tentative (that is they could have been overwritten just after the write) this
doesn't suit everybody, obviously (banking would be interesting, to say the least, in such an
environment). Solving the distributed locking problem would  be worth while - I think a distributed
server approach with each server responsible for its own locking, security etc. environment would
make the most sense. Though they would be later stages of the project, it would be worth
considering concurrent on-line backup, contingency (disaster recovery) management, availability and
capacity management as part of the design - in other words, build metrics into the fabric of the
design, don't add them on afterwards. The important question of designing the database so that it
could make time-relative queries as part of its essential fabric would have to be considered as
well - to crack that in the design in itself might make it a huge commercial success!

I'd recommend making the file system a separate project too. File systems are not part of an OS. It
is an important thing to have and there are so many mistakes to learn from. Linux, however, now has
some reliable, journalled file systems that can handle large volumes, striped volume sets, long
file names and so forth. It might be worth translating one - not a blind translation, more a
mapping of the Linux version to a detailed design, then a re-coding in Ada.

If you made a loose coalition of the three projects then they need not be dependant on each other.
The file system and db system could still run under linux, msdros, OS/X as well as interim versions
of AdaOS.

Why not put them onto sourceforge? Initially, you'd be looking at a 2-4 month design phase. I think
that quite a few experts might be encouraged to take part in advising and debating this phase
without a commitment to the development phase. That way you could be sure of a novel, reliable and
consistent design to both. If the design is right then the coding should be a doddle - if not, the
coding will be a nightmare!

In writing the project description, it might be worth while covering all the reasons why Ada is a
good choice for both - what does Ada bring to a file system and to a relation db system? Also,
design objectives for a fail-safe, highly reliable and low-error system would need to be made
explicit. If both the file system and db are designed in such a way that any of the designers would
be happy for their aeroplane or heart monitor to be reliant on the final product that might give
the right impression. There is little point in going for an Ada system that isn't rock solid from
the start - that is the design.

Careful consideration, at the design phase, would have to be given to error detection, recovery and
exception handling - after the initial design is finalised, I'd imagine quite a long period of dry
runs through edge cases, and unlikely but conceivable scenarios to establish exactly how error and
exception reporting and recovery would be handled. If these show design flaws, then the design
would have to be modified. These would have also to consider very high transaction volumes and what
they could do to the design.

You might wish to consider making these discussions private, under an NDA, there might be some
useful patents or papers as a spin-off.
---
Sent from UnionMail Service  [http://mail.union.org.za]

Re: 'Gard' - Genuine Ada Relational Database, semi-proposal

[Björn Persson]

Wa Benzi wrote:
> Why not put them onto sourceforge?
[...]
> You might wish to consider making these discussions private, under an NDA, there might be some useful patents or papers as a spin-off.

This guy proposes some development projects to be placed on Souceforge 
and then suddenly he suggests keeping them secret and patenting them? I 
can hardly believe my eyes!

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: 'Gard' - Genuine Ada Relational Database, semi-proposal

[Ludovic Brenta]

Björn Persson <spam-away@nowhere.nil> writes:

> Wa Benzi wrote:
>> Why not put them onto sourceforge?
> [...]
>> You might wish to consider making these discussions private, under
>> an NDA, there might be some useful patents or papers as a spin-off.
>
> This guy proposes some development projects to be placed on Souceforge
> and then suddenly he suggests keeping them secret and patenting them?
> I can hardly believe my eyes!

Perhaps he's trying to see if anyone is interested.  Obviously he's
never heard of Marius Amado Alves' Mneson[1], or Pascal Obry's
ADBM[2].

[1] http://www.liacc.up.pt/~maa/mneson/
[2] http://perso.wanadoo.fr/pascal.obry/contrib.html

-- 
Ludovic Brenta.

Re: 'Gard' - Genuine Ada Relational Database, semi-proposal

[Björn Persson]

Ludovic Brenta wrote:
> Björn Persson <spam-away@nowhere.nil> writes:
>>This guy proposes some development projects to be placed on Souceforge
>>and then suddenly he suggests keeping them secret and patenting them?
>>I can hardly believe my eyes!
> 
> Perhaps he's trying to see if anyone is interested.  Obviously he's
> never heard of Marius Amado Alves' Mneson[1], or Pascal Obry's
> ADBM[2].

Of course, but that's not it. It's the combination of Sourceforge with 
NDAs and patents that amazes me.

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: 'Gard' - Genuine Ada Relational Database, semi-proposal

[Maciej Sobczak]

Wa Benzi wrote:

> Why not translate this genuine relational database into Ada and throw out SQL? 

Why do you want to throw out SQL? What's wrong with it?


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: 'Gard' - Genuine Ada Relational Database, semi-proposal

[Christopher Browne]

Centuries ago, Nostradamus foresaw when Bj�rn Persson <spam-away@nowhere.nil> would write:
> Wa Benzi wrote:
>> Why not put them onto sourceforge?
> [...]
>> You might wish to consider making these discussions private, under
>> an NDA, there might be some useful patents or papers as a spin-off.
>
> This guy proposes some development projects to be placed on Souceforge
> and then suddenly he suggests keeping them secret and patenting them? 
> I can hardly believe my eyes!

Evidence of idiocy, to be sure...
-- 
let name="cbbrowne" and tld="gmail.com" in name ^ "@" ^ tld;;
http://cbbrowne.com/info/internet.html
"I think fish is nice, but then I think that rain  is wet, so who am I
to judge?"  -- Ruler of the Universe, HHGTTG

Re: 'Gard' - Genuine Ada Relational Database, semi-proposal

[Christopher Browne]

After takin a swig o' Arrakan spice grog, Maciej Sobczak <no.spam@no.spam.com> belched out:
> Wa Benzi wrote:
>
>> Why not translate this genuine relational database into Ada and
>> throw out SQL?
>
> Why do you want to throw out SQL? What's wrong with it?

Darwen and Date make a fairly comprehensive set of arguments to that
end...

Basically, it's that SQL has plenty of places where it is either
non-relational or anti-relational.

The "Third Manifesto" suggests an alternative; they start a
description of something called "Tutorial D," a more comprehensively
relational language than SQL.  It's there for "tutorial" purposes;
people are looking at more "industrialized" notions, terming it
"Industrial D."
-- 
select 'cbbrowne' || '@' || 'gmail.com';
http://linuxfinances.info/info/thirdmanifesto.html
(THASSERT (HACKER RG))
-- Example of PLANNER statement.