Accurate Logging vs A Messy Database

BonnieDundee78
BonnieDundee78 Posts: 158 Member
edited November 16 in Health and Weight Loss
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. <3 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?
«1

Replies

  • rmclyke
    rmclyke Posts: 2 Member
    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
    BonnieDundee78 Posts: 158 Member
    Yeah, I was doing the same, until I double checked my regular entries and realized some of them were incorrect! :neutral: 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!
  • Inkratlet
    Inkratlet Posts: 613 Member
    Yes, this is annoying.

    Also when people don't put the macros in when they enter stuff into the database. No use whatsoever!
  • HeliumIsNoble
    HeliumIsNoble Posts: 1,213 Member
    edited March 2017
    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
    BonnieDundee78 Posts: 158 Member
    edited March 2017
    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
    HeliumIsNoble Posts: 1,213 Member
    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
    JeromeBarry1 Posts: 10,179 Member
    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
    Keapix Posts: 92 Member
    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.
  • dammitjanet0161
    dammitjanet0161 Posts: 319 Member
    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
    kshama2001 Posts: 28,052 Member
    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
    kshama2001 Posts: 28,052 Member
    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
    rainbowbow Posts: 7,490 Member
    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
    Machka9 Posts: 25,628 Member
    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
    Machka9 Posts: 25,628 Member
    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
    BonnieDundee78 Posts: 158 Member
    kshama2001 wrote: »
    I get the syntax from the USDA database and plug that into MFP.

    Good tip. Thanks!
  • seska422
    seska422 Posts: 3,217 Member
    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.

    vu9iuliec80a.jpg
  • ladyreva78
    ladyreva78 Posts: 4,080 Member
    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.

    vu9iuliec80a.jpg

    Ooooo I like that! I might need to steal your customization somewhat. (Slowly starting to populate My Foods with my foods :smile: )
  • ThatUserNameIsAllReadyTaken
    ThatUserNameIsAllReadyTaken Posts: 1,530 Member
    edited March 2017
    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. <3 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
    BonnieDundee78 Posts: 158 Member
    Yep, I think the whole "create your own food entries" thing might be the way to go...

    Thanks everyone! :smiley:
  • Strudders67
    Strudders67 Posts: 989 Member
    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
    TimothyFish Posts: 4,925 Member
    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.
  • CharlieBeansmomTracey
    CharlieBeansmomTracey Posts: 7,682 Member
    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
    markrgeary1 Posts: 853 Member
    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!
This discussion has been closed.