I'd define a view in the database for my people (in fact, I generally
have a view defined for every model - this lets the database do the data
marshalling efficiently for counts and joins - index and show work off
views; new, edit, create, update are all off base models).
If the view is defined something like this:
CREATE OR REPLACE VIEW `peopleview` AS SELECT
`p`.`id`,
`p`.`name`,
(SELECT COUNT(0) AS `COUNT(*)` FROM `people_relations` `r` WHERE
(`p`.`id`=`r`.`person_id`)) AS `rel_count`
FROM `people` `p`;
and you create a model named peopleview, a controller and the index and
show views, then in the controller it is simple things like:
@peopleviews = Peopleview.find(:all) for the generic stuff
@peopleviews = Peopleview.find(:all, :conditions => ["rel_count>1"]) for
those multiply-related folks...
I have one example from my app...
Team has id, team_name, and team_lead (a user id)
User has id, user_name
Membership has team_id and user_id
Having a database view based on team lets my rails view 'index' show:
from teams: id (the team id, of dubious worth)
from teams: the team_name
from teams: team_lead (also an id - not very useful)
from users: team_lead_name (user_name from user)
from memberships: the membership count for the team.
The database does the joins and the counts. Since these 'manufactured'
fields are in the view, I can also use them to select and sort by. My
teamviews_controller simply has
cond = get_filter (looks at session for filter spec)
order = get_order (looks at session and parms for order spec)
@teamviews = Teamview.find(:all, :conditions => cond, :order => order)