Hi Heidi,

It's much simpler than that :) I use a centralised database and a
client database, and good use of the $useDbConfig member variable for
the Model classes, and I didn't go down the route of changing
connections on the fly either.

Models that use the central database use the 'default' settings, and
models that use the bespoke one use the 'customer' settings. I use the
hostname (client.mydomain.com) to identify each client, and set the
$customer member of the DATABASE_CONFIG class with the correct
database settings. This all happens before the user has logged in.

Hope this helps,
Richard


On May 22, 9:32 pm, Heidi Grab <[email protected]> wrote:
> Hi there,
>
> thanks Rick and Paul for your suggestions. There are some reasons why
> I think putting all clients in one db setup is a bad idea:
>
> - legal issues; for instance, one of my clients is from Poland. I am
> obliged by Polish law to save data from this company on a polish
> server, I would not be allowed to save the company data on a server
> outside of Poland; there are other countries and clients where this
> restrictions apply. Since I cannot have a database that is hosted at
> the same time in two different countries, I need to use two different
> hosts.
>
> - contract issues; some companies just want their data not be put in
> one database with data from other companies, and will only sign a
> contract if I can make sure of this.
>
> - size of data: also, companies put app. 400 new entries per day/5
> days a week into the database; starting with 10 clients, this means
> 4000 new entries a day, 80.000 new entries a month. This will slow
> queries down - since I have to keep even the old data in the database
> for now, I think it is better for performance reasons to have a
> per-client database.
>
> There may cases where two companys from the same group of companies
> are willing to put their data into one db setup, but this will rarely,
> if ever, be the case.
>
> That said, I think that I'm with Rick's approach. Rick - could you
> elaborate a bit on how you did this? Did I get you right - you had to
> compile your own cakephp shell for this?
>
> I like cakephp a lot - I am just not sure if I am going to be able to
> realize the setup I need with it; so I'd really appreciate some
> hands-on advice on how to do this.
>
> Most probably, I will have to be able to change the database
> configuration "on the fly" in the users controller. Once a user logs
> in, I have to find out what database connection holds the company
> data, and change the model accordingly. Right? Well, how would you do
> it?
>
> All the best,
> Heidi.
>
>
>
> On Sat, May 22, 2010 at 12:30 PM, rikdc <[email protected]> wrote:
> > Hi,
>
> > The configuration that you suggest is not as unmaintainable as Paul
> > might have been implying - but he does suggest the simplest and most
> > logical approach.
>
> > Some of the systems I've developed saw me at this cross road, and
> > there was always the concerned with Security issues of cross-company
> > data contamination so went for the 'database per client' approach. For
> > me, it added another layer of data security. It also kept things
> > simple from a legal point of view (Exporting data to different
> > countries), backup point of view, and server load-balancing, and some
> > of my more particular clients liked the idea their data was kept away
> > from others.
>
> > I use a central database for common data, and a database per client
> > for the rest. Each database has a different username and password, so
> > there is very little chance of Client A getting to Client B's data -
> > accidentally or otherwise. Maintenance is largely automated, I use a
> > home-brewed CakePHP Shell and Ruckusing to manage the schemas. It is a
> > bit more work as you have to be really disciplined to make sure you
> > code every database change (and test it) before deploying updates.
> > With the use of cache for the common data, there's no noticeable
> > performance issues with this approach that I've encountered so far.
>
> > Like I said, it is more work and Pauls approach is simpler but
> > separate databases keep me and my customers happier.
>
> > Hope this helps!
> > Richard
>
> > On May 21, 7:33 am, Heidi Grab <[email protected]> wrote:
> >> Hi there,
>
> >> I need my cakephp application to support multiple clients. This means,
> >> that people from company A have their very own data, and people from
> >> company B have a completely different set of data. Think of it as an
> >> issue management application: every company has their own software
> >> applications, their own staff, their own administrators that use the
> >> same web based application, but need a company-specific set of data.
>
> >> I think the best option would be to specify different databases -
> >> database A for company A right down to database Z for company Z. This
> >> could make it easy to host databases on different servers - e.g. if a
> >> company for security reasons wants to host the mysql data in their
> >> company, or if there are so many companys that one DB server just is
> >> not enough.
>
> >> How would I do this with cakephp?
>
> >> --> define a table clients that contains information on the client
> >> including which host and which database he wants to use
>
> >> --> user has client_id ; means user database would be the same for
> >> everyone; better ideas?
>
> >> --> use the specific database, e.g. the model "issues" for user A from
> >> company A is tied to database "company_A".
>
> >> Any ideas on how to make that work?
>
> >> All the best,
> >> Heidi.
>
> >> Check out the new CakePHP Questions sitehttp://cakeqs.organdhelp others 
> >> with their CakePHP related questions.
>
> >> You received this message because you are subscribed to the Google Groups 
> >> "CakePHP" group.
> >> To post to this group, send email to [email protected]
> >> To unsubscribe from this group, send email to
> >> [email protected] For more options, visit this group 
> >> athttp://groups.google.com/group/cake-php?hl=en
>
> > Check out the new CakePHP Questions sitehttp://cakeqs.organd help others 
> > with their CakePHP related questions.
>
> > You received this message because you are subscribed to the Google Groups 
> > "CakePHP" group.
> > To post to this group, send email to [email protected]
> > To unsubscribe from this group, send email to
> > [email protected] For more options, visit this group 
> > athttp://groups.google.com/group/cake-php?hl=en
>
> Check out the new CakePHP Questions sitehttp://cakeqs.organd help others with 
> their CakePHP related questions.
>
> You received this message because you are subscribed to the Google Groups 
> "CakePHP" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected] For more options, visit this group 
> athttp://groups.google.com/group/cake-php?hl=en

Check out the new CakePHP Questions site http://cakeqs.org and help others with 
their CakePHP related questions.

You received this message because you are subscribed to the Google Groups 
"CakePHP" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected] For more options, visit this group at 
http://groups.google.com/group/cake-php?hl=en

Reply via email to