Implement relational model and programming based on hash-map (NoSQL)

[linpengcheng]

It has the advantages of RMDB and NoSQL that implement relational model and programming based on hash-map (NoSQL).

This method is actually an inverse implementation of PostgreSQL. PostgreSQL Implements NoSQL support on relational models by supporting json types and extending SQL.

see my blog: Implement relational model and programming based on hash-map (NoSQL)

update: add sql-like function: join, index, select-by-index

[teodorlu]

I feel that you’re writing by analogy here. Please interrupt if I’m mis-representing, are you proposing that we structure our hash-maps as flat structures with standardized means to reference other items? So that we can have one function for generating a “default index” later?

Some things I like about flat data and your approach:

• You don’t have to understand layers you don’t use to get the data you need
• It’s trivial to model new data. You can start modeling new data at the root without knowing in advance exactly how it should relate. Just model it as-is, and move it where it belongs later.

And a final question: why not use Datascript directly?

[linpengcheng]

I think developers must fully understand the data model and be able to manipulate any data element, data transformation, and collection operations as they wish.

The data model is the most important. It should be designed before programming and adjusted as the development progresses to ensure that the data model can be easily and smoothly manipulated.

If you only need a pure relational database, I will choose postgresql, h2, honeysql.

The main purpose of my approach is to implement data modeling best practices using pure clojure core data types. The hash-map data model is designed with reference to the relational data model to:

• Like Collection operations of relational data models.

• Manipulate data elements with the powerful core functions of the hash-map in clojure.

Clojure has many facilities similar to RMDB, but lacks a relational data model. I designed this model and sql-like function. Filled in this defect. So we can call clojure an RMDB.

I did not design a complete SQL clause, because in the pure function pipeline data flow, only need to insert a reduce-kv (filter, map , etc.) in series to achieve the clause function.

               Clojure -> DBMS, Super Foxpro
                   STM -> Transaction，MVCC
Persistent Collections -> db, table, col
              hash-map -> indexed data
                 Watch -> trigger, log
                  Spec -> constraint
              Core API -> SQL, Built-in function
              function -> Stored Procedure
             Meta Data -> System Table

Rmdb is not only manipulated with SQL, The original DML of postgresql and foxpro is not SQL…

Duck Typing: If it looks like a duck and quacks like a duck, it must be a duck.

If clojure’s data model like a RMDB, clojure’s facilities like a RMDB and clojure’s data manipulation like a RMDB, clojure must be a RMDB.

According to Duck Typing theory, no matter whether clojure is RMDB or not, as long as it can be used like RMDB, it is RMDB.

[teodorlu]

I came to think of your approach outlined when reading another thread. I think that you have a good idea. I also think people might be missing what you’re saying; not necessarily being able to put together all the parts on their own.

As for me – I realize that I reach for a functional transformer of sort. A -> chain if I’m working with maps, a ->> chain if I’m working with sequences.

Have you considered creating a package for the RMDB functions (join, index, select-by-index)? With a README example or two explaining cases where RMDB is advantageous compared to nested hash maps? And perhaps with an opinionated approach to use with threading macros?

[TristeFigure]

This is you !

http://wiki.c2.com/?TopMind

[linpengcheng]

I am very happy to see this link. Regarding Table Oriented Programming, all RMDB (especially Foxpro) enthusiasts hold this view, Lua language may also be close to this view. I am a Foxpro programmer with more than 10 years of experience.

I think this linked article is too long and too complicated, and lacks an executable complete model and code. In addition, relational model programming must work with pure function pipeline data flow and Warehouse/Workshop Model to achieve perfect simplicity and Unity.