Welcome to Rails!
Your first question seems first like a modeling question. It seems to
me you want two tables. Debts and Payments. In your debt model, you
would declare has_many :payments, and in the payment model you declare
belongs_to :debt. This implies that the payments table has debt_id
field that associates each payment to a single debt. Of course if
payments can be applied to multiple debts then this breaks down and
you would need to use a third table.
The key bit here is to learn how ActiveRecord Associations work and
what they provide for you. For instance, with that structure you
could do Debt.find(:all, :include => :payments) and it would
automatically LEFT JOIN the payments and return the debts and all
their payment objects in one query. However if you only need the
total, it would be more efficient to set up a specific query using
SUM() and GROUP BY clauses to return just the data you need.
ActiveRecord supports this by allowing you to pass in the contents of
each clause in the find options (select, joins, conditions, order,
group, limit and offset).
As to your second question, what you are referring to as a global
variable sounds more like a session variable (both in PHP and Rails).
Your controller should initialize the session variable to its
default. The menu would be set up as a select menu in the view.
However, if you are re-using this menu in multiple views than I
suggest making it into a helper. If you are using declarative
scaffolding (ie. scaffold :model_name in your controller) then you
aren't going to be able to edit anything. Instead use the script/
generate scaffold ... command from a terminal to generate the code so
you can modify it. One thing to keep in mind is that controllers and
views are tightly coupled--it's more of a judgement call where to put
things. Models, on the other hand, should be completely decoupled.
That is, you should be able to use all your model code directly from
the console (script/console) without any need for the rest of the
I realize there are a lot of pieces to figure out here, but stick with
it. The key to the Rails way is knowing the purpose of each component
and where code best fits. Past experience developing web applications
will help because you understand what needs to be done behind the