📓 Notion Databases

Notions discussion of DB properties is interesting to read. Especially their relations

you get the feeling their model is indeed a real database underneath

it makes me wonder if i should consider that shape

we could export csv more easily, in fact that somewhat explains their “csv” export when you do a gdpr request. and the mapping directly to a table, calling them database (tables).

properties really do exist on every row in the table, youd probably want a file with table data, and then separately the table metadata (meaning of each column, icon, type/how to interpret it).

it doesn’t explain how something like multiselect tags work. I guess that’s a column property.

I think this would directly contradict the idea of Forms, and my plans around Logging where we’d be able to just add on log entries.

maybe logs and KV need to be separate. where KV are “real” columns on a “table” like notion, and logs is more like, contents but different

how do we handle multiple table definitions? this gets towards the “templates” a bit, that we want to define what a default Note looks like dynamically

if we have two note definitions we can take the union, but what about conflicting column definitions? do we prefix them so they’re clear? only the ones that are different? do we use the note template from the correct backend? how do we pick?

in my case this will be hidden a lot in the three repos because no one will look at a single repo individually.

so we need to have sane behaviour for e.g. a private note created based off the public template, where no private template exists. (would we encounter this if we use per backend templates?)

the roll up docs show that people might really interact with things via their tables rather than pages like i do.

i can see that, you add a property to the table and want to fill in all the elements quickly.

do we need a way to take our SQL shaped data and make it more interactive?

• we could forcibly insert ID as the first select and remove it from results, if there’s a dupe in the query no one is the wiser.
• then use that in our html output as an ID
• then provide UI (ugh) to change an attribute and save it to the backend

this really implies we need to have a central store of metadata for KV and then allow just supplying values.

that lends itself to templates. the template stores the definition of the tag, and then the values are recorded more “raw”.

well have to look up the template every time we want to render something tho.