hckrnws

Author here!

Surprised to see this on the front page again (hello fellow pottery enthusiasts?), but figured this could be a good chance to address some of the comments from the recent discussion [0] since I missed it last time :P

The most common feedback seemed to be, "this is dumb, just use SQLite", which is definitely valid.

This was actually how I initially started building the app (using SQLite), and it worked pretty well. There were a couple reasons I abandoned this approach though: one, whenever I had to uninstall and reinstall the app, the data would get wiped; two, I still had to deal with migrations and other annoying boilerplate; and three, I wanted to be able to share my results with my friends in a read-only web view.

(That being said, I'm also curious to explore how tools like ElectricSQL [1], PowerSync [2], TinyBase [3], etc. play with SQlite to handle some of these issues. At a glance, it just seemed like these would require more time to setup compared to InstantDB [4].)

Another similar comment that popped up a few times was the idea that if I'm trying to model _relational_ data, it would be ridiculous to use anything other than a _relational_ database.

I think that's fair, but I also think it's fair to say a graph database is also "relational" in some sense, or at least "relationship-centric" [5] :)

Either way, I had a lot of fun with this. And I was definitely optimizing more for speed/scrappiness than for doing it The Right Way, so if anyone has any thoughts on how to build stuff faster, I'd love to hear it!

[0] https://news.ycombinator.com/item?id=40860116

[1] https://electric-sql.com/

[2] https://www.powersync.com/

[3] https://tinybase.org/

[4] https://www.instantdb.com/

[5] https://aws.amazon.com/compare/the-difference-between-graph-...

If I understand correctly, you have a single user and a very small dataset (a few hundred KB?) Wouldn't it make sense to keep the entire dataset in memory?

* You can serialize and store the data elsewhere for backups.

* You could allow opening data dumps in read-only mode for sharing, or even generate static HTML for sharing without requiring the app.

When working with in-memory data, it's still helpful to keep the conceptual model of "tables" and ensure the data is as flat as possible, even if you are modeling something like a bare-bones property-graph. Avoid circular references, give things IDs to handle relationships, etc.

re: Graph vs SQL; The distinction between relational and graph databases is most relevant when dealing with larger datasets and lots of many-to-many, recursive or even cyclic join queries. The query language of a graph DB will be a lot nicer to navigate those joins than the equivalent SQL. But if you peek at a modern graph DB like Kuzu, the DDL the statements to create "Node" and "Rel" _tables_ look suspiciously similar to their SQL counterparts :-) [2].

--

1: https://en.wikipedia.org/wiki/Property_graphs

2: https://docs.kuzudb.com/cypher/data-definition/create-table/

> hello fellow pottery enthusiasts?

Apparently there are dozens of us software ceramicists.

If you're the author and interested in this kind of data based ceramics approach, then I recommend looking at: https://digitalfire.com/index.php by Tony Hansen. Found it awhile ago, and has:

oxide lists: https://digitalfire.com/oxide/al2o3

materials lists: https://digitalfire.com/material/list/1-9

recipes: https://digitalfire.com/recipe/list

firing schedules: https://digitalfire.com/schedule/list

ceramics properties tests: https://digitalfire.com/test/glfl

Frankly, I kind of ferret shocked when I read it. Way too much data, that nobody seems to use. Reading ceramics message boards and through Ceramics Monthly or Clay Times, they often appear to be in the dark ages from testing comparison

This is awesome. About five years ago I wanted to solve the same problem of tracking my pots and glazes. I also noticed the many:many relationship very quickly and deliberated on the schema. Neo4j looked really cool but I think I ended up going with join tables (ie pots, glazes, pot_glaze) in Postgres. I think I didn’t get nearly as far as you did in a weekend though!

Lately I hack in firebase and have been interested in trying supabase. I’ll have to add instantdb to my list.

You should productionize this! Get glaze recipes in there too!

Thanks for the kind words! And yes, I’d love to productionize this… next time I have a free weekend ;)

Discussed recently, but maybe didn't get enough attention?

Graph-Based Ceramics - https://news.ycombinator.com/item?id=40860116 - July 2024 (17 comments)

there is actual science behind this, check a glaze calculator like insight https://insight-live.com/ and component info like https://digitalfire.com

i would love something like these for oil paints and materials.

If you're trying a lot of different options you may want to check out something called Design of Experiments. [0]

0. https://en.wikipedia.org/wiki/Design_of_experiments

Very interesting, I’ll look into it!