Dinner Tagging

I returned from vacation this past weekend. It was great, very relaxing and overall a good time. Monday morning I faced the reality of the dayjob. Have you ever returned from a nice vacation just to find that certain areas in the office have quite changed for the worse? An increased political charge? Work you had counted on being finished was not touched? Maybe the timeline for your Big Project was silently cut in half?

Yeah, me either.

Anyway: Circumstance and climate sort of made committing to additional (longer) hours seem like a good idea.

On the phone with a friend of mine this evening:

Yeah, um, I guess I am going to spend some dayjob time this weekend.
Wow. That doesn't leave you much time then, does it?
Nope.
That's pretty inconvenient, considering -
Yes.

Anyway. I am trying to see the opportunity in this problem. I was talking to my ever-patient wife and exclaimed the obvious Time is of the essence! and while the dayjob eats more than its share of it, we can make an effort to optimize the little time that we do have.

Our schedules don't entirely match, so a portion of this time is taken up by sharing a meal (usually dinner) and, once a week, purchasing the ingredients for said meals as well as other, more solitary meals. These activities, I pointed out, can be optimized.

Ignoring her blank stare, I continued explaining how a little bit late-night coding and the use of tags could have the following advantages for us:

  • Quicker preparation of weekly grocery trip.
  • Quicker execution of weekly grocery trip.
  • Decreased financial impact of weekly grocery trip.
  • Prevention of wasted groceries.
  • Likely quicker preparation of daily shared meal.

The principle is easy and the involved data structures are, too. I am envisioning no more than three tables to start:

meal
----
meal_id (int)
name (varchar(255))
[...]

tag
---
tag_id (int)
text (varchar(255))

meal_tag_map
------------
meal_id (int)
tag_id (int)

Now, there are other fields that come to mind for the meal table (maybe one to hold photo of the complete meal to indicate if the selected option seems at all appealing?) and there are further ways of expanding upon this barebone database (user accounts, ingredient location within the grocery store, ...), but this is a start.

On a mere conceptual level, I could (assuming an interface of sorts) indicate a meal by its name and attach certain properties (tags) to it, such as: quick, chicken, fries, peppers, lettuce, mushrooms. A meal can have more than one tag associated with it and the same tag can of course be used for more than one meal. There lies the beauty of it, too. With this system, once populated sufficiently, it will be possible to quickly point out meals that share at least a good portion of the ingredients.

Something like this might be successful in pointing out those meals that have the tags "quick", "chicken" and "fries" then:

SELECT meal.name
FROM meal
JOIN meal_tag_map ON meal_tag_map.meal_id = meal.meal_id
JOIN tag ON tag.tag_id = meal_tag_map.tag_id
WHERE tag.text IN ("chicken", "quick", "fries") 
HAVING COUNT(*) = 3

Yes, I am all for variety in the meal plan, but a certain (maybe up to 50%) overlap probably won't hurt. This may in fact have the aforementioned five benefits.

Okay then.

Before the excitement wears off, the following three tasks remain:

  • Grab some Red Bull and hack together a UI, probably web-based.
  • Talk my wife into doing some serious data entry.
  • Persuade Keith to add a humor category to CodeSnipers. [Done! - keith]

Cheers and happy 2006.