Ok, so what you have here is a real-time logging system. There is a catch, however, because you don’t just want to see a log across time, you also want to compare log-events by category. You are recording events serially, but want to cross-check, say, waking weight with previous waking weight, etc. Then in all, you want to see where your variances are. This is a lot like load management. For example, say I want to record traffic over time on a certain stretch of road–well, obviously, I’m also going to be interested in how traffic changes based on nearby factory shift changes and weekdays.
There may be a Bluetooth scale with an app that already does this! (Who knows…)
But, to the point, you have to decide what’s the penny (or other local oxidizing currency). Here’s what I mean. Take twenty pennies and line them up by date at the near end of your desk, by your belly. Now push them toward the far end of your desk based on how shiny they are…the shinier, the further. What you expect is roughly a linear function, a line angling up from left to right. Any time you want to do an analysis, you always ask yourself “What’s the penny, and what are the characteristics I’m needing?” Here the penny was the penny, and date and shininess were the characteristics.
For your data, you have to decide what the penny is, and what characteristics are not derivable. For example, let’s say a “weighing” is the penny. Now, are the time and the meal status really distinct? If your analysis could tolerate zoning time to assume meal status, then no, they are really just time alone. If your analysis cannot tolerate that, then meal status becomes a characteristic of the weighing, like shininess for a penny. So, each weighing has 1) datetime (which is just ONE characteristic, since you can always derive weekday, etc.), 2) weight (obviously), and 3) meal status. Now, if your analysis requires comparing e.g. all pre-meal weighings no matter which meal, the meal status becomes 3) meal and 4) status.
Another solution (albeit perhaps more programmatic in its implementation) would be to make all weighings as simple as pennies: just 1) datetime and 2) weight. THEN record meals separately as each meal being 1) datetime and 2) type (lunch, dinner, etc.). Then the system would determine the rest.
Do you see how your analytic needs really determine how you set up the data?
If you wanted to learn some Base with this, you could decide what your penny is and what its characteristics need to be to do the analysis you want. I think the datetime/weight/mealstatus for each weighing is a good start. Then launch Base and check that you want a new database and that you want to go through the table wizard. Then thumb through the Business and Personal drop boxes in the table wizard and think about which one would map most closely to what you are doing. For example, there is a diet log and exercise log under Personal. You can start there and play with renaming things, etc., to see if you can build a database that has the data you need, then as time goes on learn more about aggregating that data for reports.
