Accurate Logging vs A Messy Database

BonnieDundee78

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?

Machka9

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.

U2R2

I found it marginally helpful to bookmark a direct link to the USDA database.

rmclyke

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.

BonnieDundee78

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!

Muerte55

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.

Inkratlet

Yes, this is annoying.

Also when people don't put the macros in when they enter stuff into the database. No use whatsoever!

HeliumIsNoble

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.

BonnieDundee78

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...

HeliumIsNoble

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.

JeromeBarry1

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.

Keapix

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.

zyxst

I add my own entry and don't share it. Yes, I'm clogging up the database!

TimothyFish

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.

BonnieDundee78

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.

dammitjanet0161

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.

kshama2001

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.

kshama2001

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.

rainbowbow

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.

Machka9

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.

Machka9

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.

BonnieDundee78

kshama2001 wrote: »

I get the syntax from the USDA database and plug that into MFP.

Good tip. Thanks!

seska422

I ignore the shared database and enter everything that I use into My Foods. Even doing that, I need to double-check items periodically against the packaging because companies re-test the nutritional info and change the values.

I don't share My Foods with the database so that I don't clutter it up even more and so that no one can edit and take over my entries.

Using only My Foods also lets me customize my food categories and names.

ladyreva78

seska422 wrote: »

I ignore the shared database and enter everything that I use into My Foods. Even doing that, I need to double-check items periodically against the packaging because companies re-test the nutritional info and change the values.

I don't share My Foods with the database so that I don't clutter it up even more and so that no one can edit and take over my entries.

Using only My Foods also lets me customize my food categories and names.

Ooooo I like that! I might need to steal your customization somewhat. (Slowly starting to populate My Foods with my foods )

ThatUserNameIsAllReadyTaken

BonnieDundee78 wrote: »

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.



But... since I'm not a MFP developer, any suggestions/tips on how to accurately navigate this crowded and messy database?

Yes. A bazillion times yes. The only way I have found around this is to create my own entries. I tire of correcting existing entries. There are more incorrect entries than correct ones. There could be many reasons for this. One being some people were careless when entering the info and did not proof read before adding their entry. Another is that sometimes a product gets changed a bit by the manufacturer or the label gets a correction therefore previously correct entries may no longer be correct. Just to name a couple of the many reasons.

So basically, make your own entries. They will always be in your "my foods" tab. You will find that over time you have to add less and less and you will eventually add almost everything you eat on a regular basis. So it's inconvenient at first but makes it easier in the long run.

BonnieDundee78

Yep, I think the whole "create your own food entries" thing might be the way to go...

Thanks everyone!

Strudders67

If the nutritional value has changed for what is clearly the same item, I EDIT the existing entry rather than create another new one. It annoys me how many 'duplicate' items there are. I recently found some chicken goujons / tenders in the freezer in my garage and thought I ought to eat them. The brand is Foxwood and I know I originally got them in Costco. There are 4 entries (at least) on the db for the same item. I realised, today, that the one I picked only has (had - it has now been edited) calories and no other info! One of the entries says 'UK' next to it - yet it has exactly the same nutritional values as the others (I'm in the UK and checked the packaging in ace something was different) so why on earth did anyone add that? A clean-up to remove duplicates would be good, but I guess that would affect people's historical logs. However, the end result is that the db is going to become unwieldly.

TimothyFish

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.

That 5 calorie difference is an 8% difference. On a 1200 calorie diet, 8% is nearly 100 calories per day difference. On a 2000 calorie diet it is 160 calories per day or about a third of a pound of fat per week. But what the database won't tell you is that when they were doing the testing that there may have been a 10 calorie difference between the sweetest Fuji and the tartest Granny Smith. The number listed in the database is only the average. The point is, "as accurate as you reasonably can" isn't very accurate at all when it comes to food.

seska422

TimothyFish wrote: »

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.

That 5 calorie difference is an 8% difference. On a 1200 calorie diet, 8% is nearly 100 calories per day difference. On a 2000 calorie diet it is 160 calories per day or about a third of a pound of fat per week. But what the database won't tell you is that when they were doing the testing that there may have been a 10 calorie difference between the sweetest Fuji and the tartest Granny Smith. The number listed in the database is only the average. The point is, "as accurate as you reasonably can" isn't very accurate at all when it comes to food.

But "as accurate as you reasonably can" could be the difference between "accurate enough to give me the results I expect" and "why am I not losing weight?"

CharlieBeansmomTracey

a lot of entries are going to be different as the values on food packaging change all the time. I have entries I made myself and go to use it and it be different than what it was when I first entered it. I admit I too edit entries where the package info has changed. I really hate when people put what seems like their own calorie counts and macro info in for the item.

markrgeary1

Coming from an IT environment where data is king I'm appalled at the database. I found good entries and use them.

It's sad cause with a little work, the data could be exact!