I suggest you consider "ingredients" as an entity rather than separate "items" and "fluids". ingredient would be a super-type, with sub-types of either item or fluid, while allowing for other sub-types in the future (similar to the way that in SQL Server sys.objects is a super-type, and "user table", "procedure", "function", etc., are the sub-types).
Note that since this is still a logical design rather than a physical one, "integer" just means "non-decimal", that is, the physical implementation could end up being tinyint, smallint or int.
ingredient_number integer primary_key
description character --"ground beef", "butter", "vinegar", etc.
type character ('Fluid', 'Item')
recipe_number integer primary_key
building_number integer required --references building entity
date_created date optional
date_available date required
recipe_number primary_key_1 --references recipes
input_number integer primary_key_2
ingredient_number integer required -- references ingredients
ingredient_quantity decimal required
ingredient_measurement character "ounces", "cup", "ml", etc.
instructions character optional --e.g., "stir in", "saute", etc.
output_number integer primary_key_2
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.