[Rails] Swapping DBs based on subdomains

[Steven Critchfield]

On Tue, 2005-03-01 at 09:41 -0500, Williams, Chris wrote:
> Steve,
> 
> > > Hi,
> > >
> > >         I'm in a situation where I'd like to share the exact same DB
> > > structure, controllers, helpers, models and views between two
> "teams".
> > > Each "team" needs a separate DB that has identical structure but
> > > different data.
> > >
> > > So here's the question: How do I go about setting this up? I'd like
> to
> > > do it by subdomain (but I've never even tried to set one up, so I'm
> > > lost), but would settle for a field on a User class that I can check
> > > when they login to know what team's DB to use.
> > >
> > > Basically the idea is I need multiple production DBs, but would like
> > > to share common code and structure across them.
> > 
> > While splitting the teams up by database would probably use the least
> > amount of code change, it might throw up future barriers using tools
> > like memcached as you will have to know what database the records
> where
> > pulled from.
> > 
> > You could alternately go in and add an ID to link specific records to
> > the team that is working with it.
> > --
> > Steven Critchfield critch at basesys.com
> 
> This is the approach I originally took, but it led to some ugly code and
> DB round-trips I didn't like. For a lot of pages and pull-down menus I
> had to get the logged in user, pull down their team, then filter the
> rest of the data by the team. It was ugly.
> 
> If I can make the user explicitly choose their team by the subdomain
> they enter and then use that assumption inside the associations and
> pages it makes everything much, much cleaner.

Understandable, but it doesn't stop you from still breaking the database
with team_id fields. You just parse the host name and grab the
appropriate id number. There's nothing stopping you from caching the
team name or id in the @session variable and using it to eliminate the
multiple round trips per page.
-- 
Steven Critchfield <critch at basesys.com>