Re: Mapped and memory based data files

"aplisfast" <aplisfast@xxxxxxxxx> wrote in
news:1134921436.935850.296740@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:

> I have researched a few SQL type database applications but can not
> seem to find out how they would excelerate speed to compete with
> memory based database solutions. [... deleted ...]

I think you have missed a (the?) point.

Relational databases are a standard constituent of the IT business, one
of the reasons being that they rationalise logical (application-level)
data organisation. They are not per-se about speed.

Having APL (inclusive...) able to communicate with them helps APL be
part of that wider IT world - the APL-competent can make add-ons and
data analysis tools without having to call for help translating the
data.

In that way, being able to handle relational databases widens the domain
of APL - it isn't either/or.

Equally, for a specialised application with specialised requirements,
component files, or memory-mapped files will almost certainly give
enhanced performance. As always, we can trade speed for flexibility.
In just the same way that programmers with other language preferences
might choose to abstract the data from the RDB and build their own file
structures - they can do it, and we can do it.

It may well be that - under the covers - memory-mapping may be
happening, now or in the future, within the RDB packages. We may not be
told, we may or may not care.

There's a comment further down the thread to the effect that "avoiding
RDB means we don't have to deal with DBAs". Well, they're one of the
evils of the corporate IT world. Something I found ages ago when I was
first using APL2/DB2 was that the tools there let me be my own DBA to a
large extent - I could do things to databases that the Cobol programmers
of the time had to wait for a DBA to do for them, similar things may
well be true today.

We all have our priorities - data portability stands fairly high in my
list, yours may be different.
.