Testing code for column primitive types and indexes

[healiseu]

Testing code for column primitive types and indexes

[healiseu]

Hi @josiahcarlson thank you indeed for your fast response and the extensive answers to my questions. In the future I will do try to break them in separate issues so other users and you can find it more convenient to reply.

Automated Indexing

In the current issue regarding to my Q4 about ROM internal big hash table there can be a completely different logic to handle indexing. With modern NoSQL databases like Redis it should be automated according to universal data element concepts (see Q3), i.e. attributes of an entity, and the user (developer) should only tune them. This is partially implemented in ROM with your keygen parameters and ROM's large, "hairy" hash table that is mainly there in order to handle metadata and updates.

TRIADB Indexing

Now you may contrast your approach with our associative, semiotic, hypergraph. There is one level of indexing that happens on single instance primitive data types and another level of indexing that is applied on references to the values stored. Each single piece of data, whether it is a value or reference carries its metadata and references are linked to form a hypergraph. In other words essentially you manage the references not the actual values that are stored once. Speaking about updating the index, in principal you allow add-only operations. Deletion is implemented by marking nodes as deleted and modifications are handled by changing the reference to the actual value. Single instance and reference based indexing means that on-disk, in-memory space is minimized.

Other Advantages

This approach also solves you the problem of handling foreign keys and sql joins because you have a graph with direct connections not implicit connections. Another advantage is that you can handle metadata anyway you like because each data element, i.e. hypernode, hyperedge, knows its identity and where exactly it is located. This way you can construct rows, tables, hierarchical documents and perform exploratory data analytics, ad-hoq queries, i.e. getting from any data point to any other data point on the graph.

Why I chose REDIS-ROM

That said, performance vs flexibility is a big issue to resolve in our case too and optimization is strongly dependent on the in-memory, on-disk DBMS (underlying database/data containers technology) you use. This is mainly the reason I turned to Redis and started investigating object-relational mappers like ROM to manage Redis at a higher level.

Kind regards
Athan