Brett Walker
2005-Aug-12 02:24 UTC
Cross-database referencing (was: Dynamic choice of tables for the same Model)
On Aug 11, 2005, at 5:14 AM, Zachery Hostens wrote:> if projects truly are to remain seperate then put them in seperate > databases. but this does not sound at all like what you want to do. > (note: cross-database referencing is BAD!) >The line "cross-database referencing is BAD!" really caught my attention. I need to build 2 public facing sites, and am writing a simple CMS for them. I also have to build an admin application that has to manage student and event records, etc. The public sites need to be able to access event information and register for events, etc, from the main records database. It didn''t seem reasonable to me to try and smash two CMS database and a full backend records database into one behemoth. But am I wrong about this? I don''t like having 3 separate databases - it makes managing the models that much more difficult. I could reduce it to two, by moving the records database into one of the CMS site databases. But somehow this just feels wrong - it seems better to separate the data. Any advice? Cheers, Brett
Zachery Hostens
2005-Aug-12 15:27 UTC
Re: Cross-database referencing (was: Dynamic choice of tables for the same Model)
the administration and frontend should all be one site. all (or most) of the data is going to be used at both locations so why on earth would you split it up. On 8/11/05, Brett Walker <walkerbl-O5WfVfzUwx8@public.gmane.org> wrote:> > On Aug 11, 2005, at 5:14 AM, Zachery Hostens wrote: > > > if projects truly are to remain seperate then put them in seperate > > databases. but this does not sound at all like what you want to do. > > (note: cross-database referencing is BAD!) > > > > The line "cross-database referencing is BAD!" really caught my > attention. > > I need to build 2 public facing sites, and am writing a simple CMS > for them. I also have to build an admin application that has to > manage student and event records, etc. The public sites need to be > able to access event information and register for events, etc, from > the main records database. > > It didn''t seem reasonable to me to try and smash two CMS database and > a full backend records database into one behemoth. But am I wrong > about this? I don''t like having 3 separate databases - it makes > managing the models that much more difficult. I could reduce it to > two, by moving the records database into one of the CMS site > databases. But somehow this just feels wrong - it seems better to > separate the data. > > Any advice? > > Cheers, > Brett > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Zachery Hostens <zacheryph-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Brett Walker
2005-Aug-13 16:19 UTC
Re: Cross-database referencing (was: Dynamic choice of tables for the same Model)
It makes sense when I think about it: Site A needs a CMS (content in a database) Site B needs a CMS (content in a database) Both Site A and Site B need to access a large database of event information, which is managed with its own admin interface. So you are you saying that Site A should have its CMS data as well as the event information? And then Site B accesses Site A''s event database? Or are you saying that the CMS content for both sites and the event content should all be in one huge database? Maybe I''m thinking too Object Oriented... Brett On Aug 12, 2005, at 8:57 PM, Zachery Hostens wrote:> the administration and frontend should all be one site. all (or most) > of the data is going to be used at both locations so why on earth > would you split it up. > > On 8/11/05, Brett Walker <walkerbl-O5WfVfzUwx8@public.gmane.org> wrote: > >> >> On Aug 11, 2005, at 5:14 AM, Zachery Hostens wrote: >> >> >>> if projects truly are to remain seperate then put them in seperate >>> databases. but this does not sound at all like what you want to do. >>> (note: cross-database referencing is BAD!) >>> >>> >> >> The line "cross-database referencing is BAD!" really caught my >> attention. >> >> I need to build 2 public facing sites, and am writing a simple CMS >> for them. I also have to build an admin application that has to >> manage student and event records, etc. The public sites need to be >> able to access event information and register for events, etc, from >> the main records database. >> >> It didn''t seem reasonable to me to try and smash two CMS database and >> a full backend records database into one behemoth. But am I wrong >> about this? I don''t like having 3 separate databases - it makes >> managing the models that much more difficult. I could reduce it to >> two, by moving the records database into one of the CMS site >> databases. But somehow this just feels wrong - it seems better to >> separate the data. >> >> Any advice? >> >> Cheers, >> Brett >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> >> > > > -- > Zachery Hostens <zacheryph-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Zachery Hostens
2005-Aug-14 17:42 UTC
Re: Cross-database referencing (was: Dynamic choice of tables for the same Model)
heh. if your thinking sister sites then yes same db. if there different customers they should be in different databases and not communicating. as for 2 "same" sites, different look, look into productized rails, it allows you to have a base, and grow off from there for each seperate site/customer. On 8/13/05, Brett Walker <walkerbl-O5WfVfzUwx8@public.gmane.org> wrote:> It makes sense when I think about it: > > Site A needs a CMS (content in a database) > Site B needs a CMS (content in a database) > > Both Site A and Site B need to access a large database of event > information, which is managed with its own admin interface. > > So you are you saying that Site A should have its CMS data as well as > the event information? And then Site B accesses Site A''s event > database? > > Or are you saying that the CMS content for both sites and the event > content should all be in one huge database? > > Maybe I''m thinking too Object Oriented... > > Brett > > On Aug 12, 2005, at 8:57 PM, Zachery Hostens wrote: > > > the administration and frontend should all be one site. all (or most) > > of the data is going to be used at both locations so why on earth > > would you split it up. > > > > On 8/11/05, Brett Walker <walkerbl-O5WfVfzUwx8@public.gmane.org> wrote: > > > >> > >> On Aug 11, 2005, at 5:14 AM, Zachery Hostens wrote: > >> > >> > >>> if projects truly are to remain seperate then put them in seperate > >>> databases. but this does not sound at all like what you want to do. > >>> (note: cross-database referencing is BAD!) > >>> > >>> > >> > >> The line "cross-database referencing is BAD!" really caught my > >> attention. > >> > >> I need to build 2 public facing sites, and am writing a simple CMS > >> for them. I also have to build an admin application that has to > >> manage student and event records, etc. The public sites need to be > >> able to access event information and register for events, etc, from > >> the main records database. > >> > >> It didn''t seem reasonable to me to try and smash two CMS database and > >> a full backend records database into one behemoth. But am I wrong > >> about this? I don''t like having 3 separate databases - it makes > >> managing the models that much more difficult. I could reduce it to > >> two, by moving the records database into one of the CMS site > >> databases. But somehow this just feels wrong - it seems better to > >> separate the data. > >> > >> Any advice? > >> > >> Cheers, > >> Brett > >> _______________________________________________ > >> Rails mailing list > >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > >> http://lists.rubyonrails.org/mailman/listinfo/rails > >> > >> > > > > > > -- > > Zachery Hostens <zacheryph-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Zachery Hostens <zacheryph-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>