In essence, a product and a recipe are the same thing, just a different set of information.
Let's use donuts as an example. For a store customer, they would want to know a description of the donuts, how many come in a standard order and the cost. For Brenda, she might want to know how it's cooked (fried, baked), how long to cook it, and any special instructions. But they still want to know information about donuts. So this table would serve both "customers" (I know I'm using the same term twice here, but now we're talking in terms of distinct users of the database)
Note: I'm using your naming convention while I personally would use the more traditional camel case (i.e. ProductID and ProductName). Personal preference, so if I slip and put it the other way, you'll know why....
Note2: PK = Primary Key, FK = Foreign Key
* Product_ID (id, PK)
* Product_Name (string)
* Unit_Of_Measure (string)
* Price (decimal/float depending on the DBMS)
* Method_of_Production (string)
* Special_Instructions (text or whatever your large text block datatype is)
As for Units_Of_Measure, I would leave it on product because that's where it makes the most sense. You're not going to order a dozen donuts one time and ten pounds of them another. You're either going to order singles or in dozens, so you can store the unit as each and a dozen would just have a quantity of 12, where if the unit is a dozen, then you're dealing with decimals (1 would be .083, 4 would be .33, etc)
Some things I notice in this iteration:
* ProductIngredients needs a FK to Product
* Orders has VendorID and Vendor_ID. You don't need two FKs to the same table.
* On OrderLineItems, you're missing a FK to Orders
* On OrderLineItems, the FK would be easier if it was just Ingredient_ID instead of Ingredient_Ingredient_ID. That would be a nightmare to maintain. A good habit is to be consistent, and I've found that naming the primary key as ID or PK and then on the other tables using a TableNamePK or TableNameID format makes life easier in the long run,
* Are all these sales POS (Point Of Sale) or will she be taking pre-orders? If you're taking pre-orders, there need to be dates added to the Sales table for that as well as a sale status (Paid, not Paid, Complete, Cancelled, etc)