an item model, which should have some attributes like what units to
use with it, whether it can be combined with other things, and whether
it is primitive (like your example of water. That might be debatable -
you can make water by mixing hydrogen and oxygen, or you might say
that you get fresh water by desalinating sea water).
In this particular abstraction of the world water is definitively a
"primitiv" as you call it.
Your next model could be an ItemQuantity: an item plus a quantity
(i.e. water, 0.25L) (i.e. item_quantity belongs_to :item), which
reflects a specific use of a certain item in a recipi
Then you could have a step model, where a step is a series of item
quantities, perhaps an action, i.e. uses: water 0.25L, flour 1kg,
action:mix and then a second list of item quantities: the items that
are produced, and in which quantities. You might want action to be a
separate model (perhaps contain explanations of the specific process,
e.g. cream versus fold versus beat etc.)
An Item quantity could have 2 foreign keys pointing a step. The first
would indicate that it is one of the inputs to that step, the second
would mark that it is the output of a step (and obviously an item
quantity might be the output of one step and the input of another,
although never input and output for a single step.
A recipe would then be an ordered list of steps.
I hope I will have some time this week to think about this and to
understand it all.
Neither english nor ruby are my native languages and im still
learning. Especially all about databases drives me crazy in regular.
It took me about 3 hours this morning to get a "simple" has_many up
and running. Migrating a thousand times or so back and forth.
I never know where to put the belongs_to and where the has_many, or
how to set up the migrations, where to use singular and where plural.
And after hours of trying and googling around, I found somewhere that
I cant use "has_many :attributes" because of some reserved keyword
stuff...
You should also think about what you are going to do with these
modelled items - what are the queries you are going to want to run
against your database? If the structure you come up with makes
important queries very difficult or slow then it's worth looking at
whether you can organise your data differently
Every day use will be two types of query, only when a user requests it
for a particular Item:
1. What is the recipe for this item?
2. In which recipes is this item used?
And as I am writing this I am thinking about to allow production of
fractional items for some cases. But I will wind a solution for this
myself.
A very seldom and only administrativ query would be to iterate over
all items and build up a production graph.
So far I thank you for your suggestions, I will post again if I have
any problems.
Norbert
