I would start with three tables:
ingredients
ingredient_id
recipe_id references recipes default null
name
carb_count_per_measure
measure_id
recipes
recipe_id
name
general_instructions
expected_yield
measure_id
recipe_ingredients
recipe_id ref recipes
ingredient_id ref ingredients
quantity
measure_id
add_order
add_instructions
Although an ingredient may be composed of other ingredients, it still will need a recipe. It also isn't obvious that once a recipe is prepared, that all the carbs, fat, etc. that went into making the recipe make it through. For example, water may evaporate or drain away, salt could be washed off, so totalling up the nodes may not represent the final product.
A recipe can be used to calculate the cost of the final product, or a shopping list, but if an ingredient is created by using a recipe, that new ingredient should have it's own carb_count, etc.
Now the connect by problem moves to the calculation of the shopping list, but I believe you would be better served by moving this calculation into a procedure.
Here is an example: Pasta Inc. creates a dried pasta product. Their recipe will include a little water and semolina. Most of the water will evaporate during processing, some of the semolina will be lost during the manufacturing process (shrinkage). The final product will be an ingredient in their retail store's biggest seller: Cooked Pasta. The recipe for this product will consist of quite a lot of water and salt. Most of this will be lost, some of the carbs will dissolve in the salt water that is drained away. The final weight and carb count will depend on the length of cooking the pasta. Cooked pasta will be an ingredient to the final product: Pasta with your favorite sauce. Yumm.
