Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Trilogy – A Reusable, Composable SQL Experiment

trilogydata.dev

Post reply on HN
Print view View original

41–46 of 46 posts

Re: Show HN: Trilogy – A Reusable, Composable SQL Experiment

#41

Post by emmanueloga_ »

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.

Re: Show HN: Trilogy – A Reusable, Composable SQL Experiment

#42

Post by solidsnack9000 »

hn_throwaway_99 wrote: post #13
hobofan wrote: post #9

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…

TBH, I don't think your test is very useful in real world environments. That is, you have 2 independent tables, and you're wanting the solution to depend on the fact that there are columns that are named the same across both tables. IMO these kinds of "shortcuts based on column naming across tables" usually end in disaster down the road. For example, I've been bitten in the past by "natural joins" when we've wanted t…

As far as I can tell, the parent is describing something like a trait or interface: both tables have `.firstname: text` and `.lastname: text`. This may not really be relational -- I guess there should be a third table and they should both reference it -- but it does show up in real world schemas.

Re: Show HN: Trilogy – A Reusable, Composable SQL Experiment

#43

Post by efromvt »

emmanueloga_ wrote: post #41

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…

More effort has definitely been focused on the 'select' aspect, since you often select more than you mutate - and even in the future state, for data warehousing cases updates can be relatively rare. I definitely don't see it targeting core OLTP CRUD work, where abstractions can sometimes cause more problems then they solve - but I hope for projects that involve bulk data creation, analysis, and management - analytics like - it can be a complete solution once the 'persist'/ 'export' queries are developed further.

Re: Show HN: Trilogy – A Reusable, Composable SQL Experiment

#44

Post by efromvt »

totalhack wrote: post #30

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. https://github.com/totalhack/zillion

Had some more time to drill into this and we've ended up with a very similar approach to a lot of the metadata definition and resolution - I'd love to chat sometime about how you've solved some of the common problems (table selection w/ multiple sources, the constraint vs output projection, aggregation level, etc, etc)

Re: Show HN: Trilogy – A Reusable, Composable SQL Experiment

#45

Post by totalhack »

efromvt wrote: post #38
totalhack wrote: post #30

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. https://github.com/totalhack/zillion

Oh wow yeah, a lot of parallels - thanks for sharing, I'll take a deeper dive in a bit. I think there's a lot of demand and a lot of space for different solutions; Trilogy definitely aspires to hew closer to standard SQL. (I actually really like SQL for the most part!)

Thanks for taking a look! Happy to chat, DM me here: https://bsky.app/profile/totalhack.bsky.social

I have nothing against SQL of course. The simplified approach of a UI built on top of zillion or tools like it really enables a whole next level of productivity for business users that are never going to learn SQL, but also need more query flexibility than just "dashboards" without having to wait on a BI team for answers -- I die inside a little bit every time I hear of a company doing this. And as you have noted, I also think text-to-semantic-layer is an interesting approach for involving AI/NLP.

I've been pulled away from this project for some time due to an acquisition at my day job but hoping to get back into it soon!

Re: Show HN: Trilogy – A Reusable, Composable SQL Experiment

#46

Post by efromvt »

totalhack wrote: post #45
efromvt wrote: post #38

Earlier quoted context omitted.

Oh wow yeah, a lot of parallels - thanks for sharing, I'll take a deeper dive in a bit. I think there's a lot of demand and a lot of space for different solutions; Trilogy definitely aspires to hew closer to standard SQL. (I actually really like SQL for the most part!)

Thanks for taking a look! Happy to chat, DM me here: https://bsky.app/profile/totalhack.bsky.social I have nothing against SQL of course. The simplified approach of a UI built on top of zillion or tools like it really enables a whole next level of productivity for business users that are never going to learn SQL, but also need more query flexibility than just "dashboards" without having to wait on a BI team for answe…

Also full agreement! In an optimistic view, the SQL layer (at a slightly higher level) unifies the top level accessibility tools (NLP, drag/drop chart result builders, etc) with the more tech-familiar level of analysts/engineers, and provides progressive disclosure as you go down the stack and a path to promote the adhoc/SQL level work up to reporting easily.
Post reply on HN