I'm working on a non-programmer friendly database app (q.v. FileMaker). What do folks here consider the best work in non-programmer query interface (i.e. not using a query language, but a GUI)?

Google search and suchlike

Assume a proper relational database, with predefined statically typed tables and all. FileMaker and Access and the like usually present a form query interface, basically the same as the row entry form, where you can fill in values for some of the fields, or perhaps provide constraints, and then we get a query from that. I’m wondering if anyone has created something better.

Ultorg is great! I also really like datasette. Good call.

I think I might have actually built the best data interface for non-programmers at work. (Databricks has a similar one called Genie). You talk in prose and it generates SQL + a grammar-of-graphics visualization of it. Then you take the in dialogue charts and pin them to a dashboard, so the dashboard has no AI, but the exploratory conversation does. The underlying SQL and data tables are browsable.

I have a few things I’m trying to do with this project. One of them is to popularise Datalog. For everyone, really. I think anyone who can learn to write Excel formulae can learn Datalog and get a darn sight more out of it more quickly than they can trying to learn SQL. But I love what you’re doing there. Just like we need mathematical formulae to communicate mathematical ideas with each other, I think we will want to communicate with AIs using maths and using Datalog.

Why is Datalog better than SQL for relational data?

Because SQL is an abomination of a language designed by IBM and popularised by the CIA (https://frest.substack.com/p/how-the-cia-ruined-programming), while Datalog is concise and elegant. The biggest single mistake in the computer industry (bigger than null) was synonimising “relational” with “SQL”. This meant we think the only use for relations is in heavyweight on-disk OLAP databases. In fact, the relational model is more or less the canonical theory of “declarative” and should be used pervasively in programming. Our programs should be in significant part Datalog, with Turing Complete and side-effecting code inserted wherever that is necessary.

I researched it and I think datalog composes better would be my summary. So if you had a a linked knowledge base in relational data you would be able to express knowledge extraction queries better maybe?!

My project is to build a kind of FileMaker plus. Yes, it’s a personal database, but in the same query interface, you can join any and all kinds of sources of data I can get in there: your email, your filesystem, the contents of those files, weather APIs, mapping services, … So Datalog works well here, since many of the sources of data you’re joining aren’t SQL underneath, anyway, and the ones that are all speak different SQL dialects.

Datalog from the clojure community?

Maybe worth exhuming Paradox for DOS' "Query by Example"? Haven't thought about it in 30+ years.

@Jeroen van Dijk Datalog comes from the PROLOG community in the 70s. Datomic (from the Clojure community) borrows from it, as does SPARQL (the query language of the semantic web).

reading https://pages.iai.uni-bonn.de/manthey_rainer/IIS_1819/IIS18_Chapter2.pdf what a scathing comparison from a lecturer of Datalog! But this was 2018 and I do think Datalog is beginning to show up in industry, I only hear about it in IAM systems though.

The “not used in industry” bit was bogus even in 2018. There is not widespread use of the 70s PROLOG embedding, but SPARQL is used in many places and Datomic is surprisingly widely deployed in industry. (I worked on deductive databases for ~20 years, created the standard algorithms in many textbooks, &c, so this is an area where I’m especially sensitive to FUD.)

I like Airtable's query builder, which matches what you describe of a tree of predicates, but also with grouping.

For visual sql, I remember this work by Chartio making the rounds. Looks like they closed down though. https://chartio.com/blog/why-we-made-sql-visual-and-how-we-finally-did-it/