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.
@lukasros I used to, but I changed browsers/phone and never got around to setting it up again; Blurby keeps me on Telegram.
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.
@jws 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
+ timeofday
+ orderstyle (à la carte, set menu)order_description (i.e. name of the set menu)
- bill_currency
- bill_value
meals_courses:
meal_id
course_number
+ course_typecourse_description
coursenotes
+ winekey (links to table "wines")winepairingnotes
course_types: main, amuse-bouche, hors d'œuvre
Not easy.
// @matigo
@jws Another thing would be recording whether I went for breakfast, lunch, or dinner, how I ordered (set menu vs à la carte), etc.
// @matigo
@jws - 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.
// @matigo
@matigo Is there any system that can be relational but is also as flexible as JSON?
@matigo That has generally been my experience. JSON looks so new and wonderful and easy :P