I might be off here, but this seems like the right place to ask: don't most SQL replacements focus heavily on querying while largely overlooking insertion and updating?
I get why querying gets more attention, insertions are usually straightforward and don’t need much simplification. Updates, on the other hand, can be a bit trickier since they often involve modifying data derived from complex queries. These tools seem geared toward data analysis and not data generation, which is ok: is nice focusing on a single problem and solving it "right".
But! for projects where a single person handles data creation, analysis, and management, it feels cumbersome to use one set of tools for querying ("R" in CRUD) and another for creation, updates, and deletions ("C," "U," and "D"). I think a "SQL replacement" or approach covering all of CRUD could be interesting for projects of any scale. Something that I could pick instead of shopping for ORMs and/or lightweight query generators.
Congrats on the launch. I made a tool that has some similar objectives but doesn't present as SQL itself like Trilogy seems to. I'll take a deeper look at Trilogy soon, always interested to see the variety of approaches to this.
This is great; I have been thinking about this for a long time. I like reading about past and current implementations that try to better sql; from a programming and a data science and performance perspective. I am aware of the ones you linked and some others like 'Real' (shakti.com) sql and some enhancements from papers.
Anyway; nice one! Will try.
Cool project!
Will take a proper look when I get a chance.
In the meantime, I just wanted to say: nice name! ;-)
Not a SQL replacement, but if you're looking for an open source semantic layer, Cube is the way to go [0]
[flagged]
One thing that I am always looking for in a new "reusable", "composable" SQL tool is reuse of the same analytical queries across different source tables.
My litmus test:
I have a table "people" with the columns "people.firstname", "people.lastname", and a table "persons" with the columns "persons.firstname", "persons.lastname". I now want to create a query that gives me the "fullname" (".firstname" + " " + ".lastname") of all rows of both tables. If I have to spell out the logic for how to calculate the fullname in the query twice, the test is failed.
(Taking the shortcut of creating the union of both tables first is not allowed, but I can't think of a simple example that enforces that restriction).
For some reason, all of the solutions (PRQL, Malloy, dbt) that try to make SQL more reusable don't really consider this kind of reuse, and with that ultimately fall flat for the use-cases I would typically have for them. Sadly, Trilogy doesn't seem to be any better on that front.