Need help figuring out how to implement a change feature

Im working on a website that is a recipe database and want the users to be able to submit changes to the recipes and other users can vote on the changes. However the various methods Ive been trying I come across limitations and wondering what the best method would be to handle this and looking for some advice on how to attack this problem. Here is some info on my setup:

Database Structure:

Recipes table - has columns for singular items like servings, cook time, description, photo, etc

RecipeIngredients table - just like it sounds, holds all the ingredients for all recipes has amount, unit, name, recipe_id columns

RecipeSteps table - same as ingredients has order and description columns

Here is the various details/issues of the feature Im looking to implement and what is causing me problems:

  1. Initially was going to have an ingredient_change and step_change table and address individual changes to items…but an ingredient change can effect the steps so needed to have a single change with multiple items

  2. Looked at recreating the entire recipe everytime there is a change submitted but that seemed like an excess of storage and would eventually cause the database to be way to big

  3. Currently Im trying to have a simgle change table that stores the changes as a json string but having a lot of trouble figuring out how to implement it and build a form that has all the ingredients and steps that changed and save it as a json.

So to sum up and hopefully clarify some. Im hoping to get some help on figuring out a way to go about allowing users to change something on the recipe, save just the changes to a database and know what is different about the changes to show the users who vote. Hopefully this is clear enough to understand

Have you looked at any of the versioning gems -- Paper Trail, Vestal Versions, etc. ? There's several listed here: https://www.ruby-toolbox.com/categories/Active_Record_Versioning If you versioned both of your tables, then you could roll back to any point in time (the last time that the recipe was "approved" or voted to consensus) for the public view, while showing (and accepting additional changes to) the latest version for voting purposes. I'm not clear what your intent is for the voting here...

Walter

Yeah and I am using papertrail for once the changes are voted on and get applied…

The voting is basically a way for the community to decide on how to improve recipes…once a change is submitted it isnt applied and wont be unless enough other users vote that it is a better change. So basically I dont want to save it to the recipe unless it gets voted…im basically trying to do what papertrail trail does but on my own so I can only apply what fields I want (those that change and not the whole recipe) and only if enough positive votes.

I have had a minor break on this thinking like papertrail and im working on creating a form to a custom method in the controller and creating the change based on that instead of pushing it to the recipe table.

Im working on a website that is a recipe database and want the users to be
able to submit changes to the recipes and other users can vote on the
changes. However the various methods Ive been trying I come across
limitations and wondering what the best method would be to handle this and
looking for some advice on how to attack this problem. Here is some info
on my setup:

Database Structure:
Recipes table - has columns for singular items like servings, cook time,
description, photo, etc
RecipeIngredients table - just like it sounds, holds all the ingredients
for all recipes has amount, unit, name, recipe_id columns
RecipeSteps table - same as ingredients has order and description columns

Here is the various details/issues of the feature Im looking to implement
and what is causing me problems:
1. Initially was going to have an ingredient_change and step_change table
and address individual changes to items...but an ingredient change can
effect the steps so needed to have a single change with multiple items
2. Looked at recreating the entire recipe everytime there is a change
submitted but that seemed like an excess of storage and would eventually
cause the database to be way to big

I will suggest this isn't actually true. Database systems can store a hecka
lot of data without worries. Recipes aren't huge amounts of data at that.
You would need to be getting up to the 100's of millions of recipes well
before you have any such issues, by which you'll also have encountered
other sorts of scaling problems.

You could go through and prune submissions if they get sufficient negative
votes, but I'd suggest this also isn't likely.