The magic of small databases

Datasette is great! I'm not very familiar, but here is my impression :

I guess my working definition is about the "default mode". So the (Datasette) Lite version could indeed be "no code" in a similar fashion to the "BI platforms" category above, that is, for read only advanced exploration.

In a deeper sense, "no-code" is also about how the software is designed for the ground up. This may include visually customising/configuring most of the settings/plugins and all those delicate UX touches for the "average-user".

Personally, I'm waiting for two things : better facets and support for multivalued columns (I really like my openrefine for local or polymersearch for online)

I'm going to plug our related project: TreeBase. It's the public domain software that powers PLDB.com (a Programming Language DataBase).

It's very simple. If your small database was about cars, your structure might look something like this:

    database/
     grammar/
      engine.grammar
      interior.grammar
     things/
      model3.car
      camry.car

The `grammar` files are written in a Tree Language called Grammar. Those are your schema files. You basically create a new syntax-free plain text "language" for storing your data, in this case 1 "car" file per model of car.

It was a pipedream of mine until the M1's came out. Those changed everything, because then it became fast enough to actually do it.

We have a new release coming out soon with a new query language that will change everything. Here is the source code: https://github.com/breck7/jtree/tree/main/treeBase

I love this. I've been thinking about something similar lately. There are so few good indexes and search engines for niche collections of data.

Imagine if there was a niche search engine for everything, and the search engine was customized for that niche.

I think the main problems here are:

- Data format and ingestion - Domain-specific indexing/relevance

Most data is super messy and it not accessible through nice APIs, which presents a problem. You might need custom ingestion for each niche and it's pretty likely you'll need some rules to standardize data from multiple sources, neither of which seems easy to generalize and automate because they're very domain-specific.

The other part to this is indexing/relevance so the search feels good to use. Some fields are obviously going to be more important than others and people are going to want to utilize search for things that are to predict ahead of time.

To use the authors example of artists in Brooklyn, people might want to search for artists near them. Now you have to gather location data, format it, ingest it, index it and add it to the search UI.

The fact that adding another field to index on is a vertical integration adds a lot of overhead.

All of this stuff in isolation is not difficult, but when you put it together it becomes quite a lot of work that generally isn't easily scalable.

I don't understand. How would you use LibreOffice to build a collection of object photos and descriptions, with custom descriptors and normalized data references, that could be deployed as a searchable / filterable website?