Wow. That talk on linguistics and perception was really enlightening, and that speaker's research [mpi.nl] has…a damn lot on olfactory sensitivity across linguistic communities and wine experts. Almost all of it openly and fully available too, which is a very pleasant change.

I used to, but I changed browsers/phone and never got around to setting it up again; Blurby keeps me on Telegram.

Tell me more…
//

Have thought about it for a good 30 minutes now and it seems like JSON would be lovely, but ultimately the restaurant notes should go into the same sqlite3 db that all the tasting notes are in. Doesn't make sense to maintain related information across 2 systems.

Telegram syncs drafts pretty quickly, which makes it a quick Non-Apple way to share links between phone and computer.

The data input is also another issue, but it seems designing a form of some sort wouldn't be impossible. Since reading your post I've come up with this where + is a foreign key; restaurant names and addresses would go into the existing "sources" table:

meals:

  • mealid
    + time
    ofday
    + order
    style (à la carte, set menu)

  • order_description (i.e. name of the set menu)

  • bill_currency
  • bill_value

meals_courses:

  • meal_id

  • course_number
    + course_type

  • course_description

  • coursenotes
    + wine
    key (links to table "wines")

  • winepairingnotes

course_types: main, amuse-bouche, hors d'œuvre

Not easy.
//

Another thing would be recording whether I went for breakfast, lunch, or dinner, how I ordered (set menu vs à la carte), etc.
//

- dinner-fkey would necessitate 2 more tables: dinners (which would basically end up looking like a calendar), and restaurants (a yellow pages-like table).

  • Course number works as long as I don't take notes on the amuse-bouche, petit-fours, hors d'œuvres etc.

But if there is one reason to keep it in the same database as my wine notes, it is that I could more easily refer to the wine that I drank with that course, and keep the wine notes in the wine table — then there'd be no overlap.
//

Is there any system that can be relational but is also as flexible as JSON?

That has generally been my experience. JSON looks so new and wonderful and easy :P