gcobol: a native COBOL compiler

> For the record, I believe a few modern relational DB have some sort key/value store backing them (e.g. cockroachdb, IIRC).

And, we use Toad at work to access Oracle. Which gives me the IMPRESSION that Oracle is one of them.

> And as far as index joins being fast, once you get to non-trivial data sizes, many dbs are column oriented with no indexing available. I'm guessing because storing indexes for that much data becomes unmanageable. Unless you count bitmaps as an "index".

Interesting. I would have thought that's a solved problem. Certainly in Pick it is. We have the concept of a data segment, in which ALL data is stored, an index is just another data segment. It's managed by the DB, but you can create a data-pointer to it and it looks to all the world just like any other data file. It just contains your index field and your record id inverted. Oh and because we have the concept of calculated columns, you can create ONE index on MULTIPLE columns dead easy - just index a virtual field! Just don't create your virtual index using other virtual fields, as Pick won't spot the other table has changed, and will leave you with a corrupt index.

But in other words, if your index is too big, then surely your data is even more too big ...

> Of course, this is all true.. until hardware makes your non-trivial data trivial again, many features are rediscovered, and the circle is complete.

Exactly the "throw hardware at the problem" attitude I hate, rather than using smarts to avoid wasting energy and throwing brute force at it.

Cheers,
Wol