Re-structure ingredients to be more robust

[dpopp07]

From James:

Ideas for future-proofing our data:

Ingredients as objects instead of strings (and their own table)
    Own table b/c a lot of drinks might have the same ingredient
    Object b/c maybe we care about some other stuff like
        subsitutes
        image url
    Object because maybe we want stuff like optional to be a boolean flag
    Object because then we can use unique IDs (altho we could do this w/ strings rn) to allow for things like sorting by ingredient, filtering by ingredient, "look up what drinks you can make based on ingredients you have"

Acceptance Criteria:

• Structure of an Ingredient defined
• Functionality defined for adding a drink, validating the drink object against the ingredients database

[dpopp07]

I've been thinking about this and I have a proposal. I don't want to have to use pointers to another table from within the Drinks table because that would require a DB lookup for every ingredient (best case, assuming we're caching, which we're not right now). NoSQL best practice recommends using as few tables/joins as possible. That said, I appreciate the need for consistency across ingredients for filtering, etc.

So! My proposal is - have an Ingredients table the master blueprints of every ingredient. When a drink is created, all ingredient objects are validated against this table but the Drinks table just contains the raw, nested objects. These can even include the unique IDs assigned by Rethink, pulled from the Ingredients table at drink creation time. Drinks will be created far less often than all the drinks will be queried so I think this is more efficient. Even updating an Ingredient would be a simple operation to update all the drinks containing that ingredient if they have IDs attached to them

Let me know what you think!