Accurate Logging vs A Messy Database
Options
BonnieDundee78
Posts: 158 Member
First let me start by saying that I LOVE MFP. And I'm 22.5lbs down in 9 weeks so, believe me, the love is real. But I'm short, so my calorie target is low (1300), and my goal weight maintenance is only c.1600. I don't have a big margin of error to play with, so I'm trying to develop good logging habits now, because I know accuracy will be super-important in order to hit and maintain my goal weight.
So here is my grumble: The number of incorrect or incomplete entries on the database makes logging accurately far more difficult and time-consuming than it needs to be.
And the green user-generated checkmarks are NO guarantee that an entry is accurate/complete, which make them kinda pointless...
It is particularly bad for generic/non-packaged foods, especially fruit and vegetables. Even when I search for the USDA version, I often get multiple results, with different values, and I have to head over to Google to track down the "official" nutritional values, then back to MFP to find an entry that is correct. I confirm the accurate ones I find.
I'd find it so helpful if MFP could do some official checks, and have a different coloured check mark or symbol that indicates "This entry has been checked by the MFP team and represents current USDA nutritional data". And then make it non-editable. A single version of the truth would be so helpful. There shouldn't need to be multiple entries for "Brussel Sprouts, Raw" (or whatever...)
I understand that the database is free (!), and user-generated, and that's where a lot of it's power comes from, but it also makes data cleansing and general housekeeping very important!
But... since I'm not a MFP developer, any suggestions/tips on how to accurately navigate this crowded and messy database?
So here is my grumble: The number of incorrect or incomplete entries on the database makes logging accurately far more difficult and time-consuming than it needs to be.
And the green user-generated checkmarks are NO guarantee that an entry is accurate/complete, which make them kinda pointless...
It is particularly bad for generic/non-packaged foods, especially fruit and vegetables. Even when I search for the USDA version, I often get multiple results, with different values, and I have to head over to Google to track down the "official" nutritional values, then back to MFP to find an entry that is correct. I confirm the accurate ones I find.
I'd find it so helpful if MFP could do some official checks, and have a different coloured check mark or symbol that indicates "This entry has been checked by the MFP team and represents current USDA nutritional data". And then make it non-editable. A single version of the truth would be so helpful. There shouldn't need to be multiple entries for "Brussel Sprouts, Raw" (or whatever...)
I understand that the database is free (!), and user-generated, and that's where a lot of it's power comes from, but it also makes data cleansing and general housekeeping very important!
But... since I'm not a MFP developer, any suggestions/tips on how to accurately navigate this crowded and messy database?
20
Replies
-
I refer to this site if I'm not sure: http://nutritiondata.self.com/
And now I've got my usual foods in my Frequent/Recent list so my logging is quite quick and I can ignore the "noise" in the rest of the database.10 -
I found it marginally helpful to bookmark a direct link to the USDA database.8
-
If there are too many discrepancies for a food in the database and if it is a food I use often I add it to my foods and log from there.1
-
Yeah, I was doing the same, until I double checked my regular entries and realized some of them were incorrect! I had chosen poorly the first time I selected them, and then kept using the same entry. Currently going through my Frequent/Recent lists and double checking everything!1
-
In the same breath, how hard is it to read a label, and transfer the information from that label to the database. It's not rocket science !! I'd like a dollar for every one I have corrected, I could eat some good lunches.6
-
Yes, this is annoying.
Also when people don't put the macros in when they enter stuff into the database. No use whatsoever!3 -
I think the data entry form for submitting a new food should have a field for sodium and a field for salt. Lots of people are entering the salt level off the back of the pack in the sodium field, without converting it first.
I would like to see a salt field in grams, and have the site coded to be able to generate the sodium value from that, just like it can produce the calorific value for 55g of jelly beans, once someone has updated the database with the calorific value for 100g of jellybeans.2 -
YES. The sodium g/mg thing is a minefield. I have to change them ALL THE TIME. No wonder some people eat too much salt if they can't tell the difference between grams and milligrams...0
-
Yep, let's not even get on to the unit errors. I once bought a pack of frozen sausages, and found the product had four entries, ALL of which had the serving size values confused with the values per pack or the values per 100g.
0 -
OP, I share all your concerns.
I keep one browser tab open on https://ndb.nal.usda.gov/ndb/search/list
I have an Excel spreadsheet with conversion values for vitamin A in RAE, C, Calcium, and Iron to convert the "mg" values in the usda database into RDA percentages. I use 900 mg for A in RAE, 90 mg for C, 1000 mg for Calcium, and 18 mg for Iron because 18 is the number needed by fertile women.
Men need less iron, but men use this database less so there.
I source those values from https://ods.od.nih.gov/factsheets/VitaminA-HealthProfessional/ .
I don't verify every value of every item every day, but when I am adding a new item I do check, and often find that the A, C, Calcium and Iron values are not accurately converted to RDA percentages, but rather are raw mg values.
When I change a database item, I note the change, the date, and sign with my initials.
1 -
HeliumIsNoble wrote: »I think the data entry form for submitting a new food should have a field for sodium and a field for salt. Lots of people are entering the salt level off the back of the pack in the sodium field, without converting it first.
I would like to see a salt field in grams, and have the site coded to be able to generate the sodium value from that, just like it can produce the calorific value for 55g of jelly beans, once someone has updated the database with the calorific value for 100g of jellybeans.
I wish they would add a salt field; it's inconvenient to do a conversion each time, and sodium isn't listed on packets here.0 -
-
I think people put far too much importance on accuracy. Accuracy is impossible. Consider the lowly apple, for example. Apples are a favorite among dieters. But there are thousands of varieties of apples and you may find twenty varieties in your local grocery store. It would be impossible for someone to have an official verification of every variety of apple. I doubt that every variety of apple has even been tested for calorie content, so how could anyone possibly verify it. Most people probably just log a generic apple, but there is a significant difference in calorie content from apple to apple. A Fuji Apple is sugary sweet and most certainly has more calories than a Granny Smith Apple which is tart. Even if that information were in the database, the time of year that an apple is bought can have a significant impact on the accuracy. In season, apples are sweeter. But apples sold out of season were picked green and have less sugar. No one can account for all of that. And you have the same situation with everything in the database.
Rather than worrying about accuracy, our aim should be to get in the ballpark and adjust from there.5 -
100% accuracy is impossible, of course. But there's no reason not to be as accurate as you reasonably can. e.g. There's a 5 cal difference between Fuji and Granny Smith apples based on their 100g weights. It's not that hard to check.5
-
HeliumIsNoble wrote: »I think the data entry form for submitting a new food should have a field for sodium and a field for salt. Lots of people are entering the salt level off the back of the pack in the sodium field, without converting it first.
I would like to see a salt field in grams, and have the site coded to be able to generate the sodium value from that, just like it can produce the calorific value for 55g of jelly beans, once someone has updated the database with the calorific value for 100g of jellybeans.
OMG, this is the bane of my life when looking up new foods! I'm another serial correcter of salt into sodium.
I did once post a question in the MFP help section asking for this very thing but it was ignored.0 -
BonnieDundee78 wrote: »YES. The sodium g/mg thing is a minefield. I have to change them ALL THE TIME. No wonder some people eat too much salt if they can't tell the difference between grams and milligrams...
I swapped out Sodium and Sugar for Iron and Fiber, which are more useful nutrients for me to track.3 -
The ridiculously cluttered database is one reason why I would never pay for Premium, which uses the same DB.
Unfortunately, the green check marks are used for both user-created entries and system entries. To find system entries for whole foods, I get the syntax from the USDA database and plug that into MFP.
For packaged foods, I verify the label against what I find in MFP.4 -
kshama2001 wrote: »The ridiculously cluttered database is one reason why I would never pay for Premium, which uses the same DB.
Unfortunately, the green check marks are used for both user-created entries and system entries. To find system entries for whole foods, I get the syntax from the USDA database and plug that into MFP.
For packaged foods, I verify the label against what I find in MFP.
This is exactly my sentiment.3 -
I've never paid much attention to salt/sodium. I know I don't get enough of it, but that's easily solved by salting my food or taking an electrolyte tablet.0
-
BonnieDundee78 wrote: »100% accuracy is impossible, of course. But there's no reason not to be as accurate as you reasonably can. e.g. There's a 5 cal difference between Fuji and Granny Smith apples based on their 100g weights. It's not that hard to check.
5 cal wouldn't bother me ... I'd just go with the larger number of calories.
Funny thing ... because I tend to go with the larger number of calories, it was a year before I discovered that two of my main food entries were quite a bit higher than what they actually were. I had been recording one as about 175 cal, and turns out it was about 125 cal. I had the other at about 100 cal when it was really about 50 cal. I don't think I changed them, just left them at the higher amounts.1
Categories
- All Categories
- 1.4M Health, Wellness and Goals
- 391.6K Introduce Yourself
- 43.5K Getting Started
- 259.7K Health and Weight Loss
- 175.6K Food and Nutrition
- 47.3K Recipes
- 232.3K Fitness and Exercise
- 393 Sleep, Mindfulness and Overall Wellness
- 6.4K Goal: Maintaining Weight
- 8.5K Goal: Gaining Weight and Body Building
- 152.7K Motivation and Support
- 7.8K Challenges
- 1.3K Debate Club
- 96.3K Chit-Chat
- 2.5K Fun and Games
- 3.3K MyFitnessPal Information
- 23 News and Announcements
- 931 Feature Suggestions and Ideas
- 2.3K MyFitnessPal Tech Support Questions