RE: Swapping DBs based on subdomains

Steven Critchfield
2005-03-01T22:56:02Z

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-wQLwMjUOumVBDgjK7y7TUQ@public.gmane.org
>
> 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-wQLwMjUOumVBDgjK7y7TUQ@public.gmane.org>