Re: RDBMS using hashtables

On 2014-08-26, Derek Asirvadem <derek.asirvadem_at_gmail.com> wrote:
>> On Friday, 4 October 2013 23:09:08 UTC+10, Alexander Langer wrote:
>> Hi all,
>>
>> do you know read-optimized RDBMS software using hashtables and order
>> preserving hash functions instead of trees ?
>>
>> do you know read-optimized RDBMS software
>
> Most commercial RDBMS is heavily read-optimised already.

True, of course.

> Non-commercial RDBMS are not RDBMS, or even DBMS, they are merely freeware
> that has a few file handling capabilities,

Nonsense, partly because it is just wrong as it is stated, and partly because there are commercial "RDBMS" which are also not actually "RDBMS".
> Further, they have very little *R*elational capability.

True of some freeware, and some commercial products, but also not true of others in both categories. Of course complete *R*elational capability is pretty much missing everywhere.

> Some of them fraudulently claim to be SQL, it is a fraud, because they
> do not comply with, or provide the facilities of, SQL.

Providing an adequately documented subset is not fraud, and you can check to see if everything you actually need is there.

>> using hashtables *and* order-preserving hash functions instead of trees ?
>
> Well that is a contradiction, so you won't find that in a commercial
> platform (you might find it in freeware).
>
> The contradiction is this. "order-preserving" requires trees, an *order*
> implies a tree. "hash function" has no order. Therefore you can have
> one, XOR the other, but not both in the same table.

Totally wrong. Order-preservation does not necessarily require a tree, and order-preserving hash functions do exist.

> --
>
> The RDBMS does not need to implement hash-tables, in order for you to
> have hashed access...

The rest is probably mostly true, but also irrelevant to the OP's question as I understand it.

Eric

-- 
ms fnd in a lbry