The in-memory database library I've been working on during the recent months is now on Github.
Persistence is provided through snapshots. For the future I'm planning to add the ability to restore data from a transaction log.
Tables are implemented using hash tables, so specifying a key using PRIMARY KEY is required.
Although I think enough of SQL is implemented to be useful, there quite a number of desirable features is not implemented yet. I'm interested in feedback about what should be added next.
SQL is such a terrible language though, for inspiration look at https://www.arangodb.com/docs/stable/aql/tutorial-crud.html#update-documents
Feel free to ignore the JSON parts, but the rest of the query language is well done.
I did write SQL queries that were multiple pages long full of joins and group by statements. I prefer nested foreach loops (with hand written accumulator sets for grouping) over SQL's poorly done "declarative style".
I share Araq's dislike for SQL, but there is at least one "declarative style" SQL-like language that I've used that does work extremely well, called "kdb+/q" or RealSQL, depending on which incarnation you look at.
It is much simpler, and has a few things going for it - such as embracing order of records (which SQL has a love-hate relationship with, which makes a lot of things extremely awkward to the point of being unusable) and doing automatic foreign key chasing, which is so logical and useful that it's word SQL insists you explicitly join everything.
For example, this ANSI sql query:
select o_year,sum(case when nation = 'BRAZIL' then revenue else 0 end) / sum(revenue) as mkt_share from (
select extract(year from o_orderdate) as o_year, revenue, n2.n_name as nation
from t,part,supplier,orders,customer,nation n1,nation n2,region
where p_partkey = l_partkey and s_suppkey = l_suppkey and l_orderkey = o_orderkey and o_custkey = c_custkey and
c_nationkey = n1.n_nationkey and n1.n_regionkey = r_regionkey and r_name = 'AMERICA' and
s_nationkey = n2.n_nationkey and p_type = 'STEEL') as all_nations
group by o_year order by o_year;
Becomes (for exactly the same table definition)
select[order.year]revenue avg supplier.nation=`BRAZIL from t where order.customer.nation.region=`AMERICA, part.type=`STEEL
(This is TPC-H National Market Share Query 8 from the TPC-H benchmark)
Most of the part missing in the second part is simply automatic foreign key join ("chase") , although there are other things that make the query simpler as well.
This is implemented and included in a programming language environment derived from APL (of which earlier versions were called "k" and the newest version is called "shakti"). The language itself is quite niche and virtually unheard of outside of finance (and is unpopular with many people), but the query language is much nicer to use than SQL.
automatic foreign key chasing, which is so logical and useful that it's weird SQL insists you explicitly join everything.
Yes! That was among the first things I added to Ormin. It's ridiculous standard SQL lacks this.
This is just my experience:
Files only in single key -> read, update
Logics should be seen -> only in reading
Joins -> read only
With that I never had a mistake. (on my career) I may be severe but a database is the heart of the business, whether accounting or production ...
I sometimes find the way to manage transactions light, unless I generate in ECPG which is very respectful to it. BEGIN transaction requires a commit or a ROLLBACK for example it's true I come from DB2 AS400 and rigor is his first name
Some functions are missing in libpq.
But it's a great Postgresql engine
I searched in Ormin very very interesting
when can we use NimternalSQL please
Neat! It looks as though it's not aimed at high performance, though, since I didn't see any support for indexes in the source code.
I'm kind of working in the opposite direction — I've got a Nim API for libmdbx, which is extremely fast but just a raw key/value store. I'm adding indexes to it now and plan to add structured data. (I've got an earlier project in C++ using libmdbx that supports a subset of SQL.) It might be interesting to join our projects.