2009/1/25 mguthrie <[email protected]>: > > That's fair. It would pretty much be a specialized Customer Relationship > Manager (CRM) geared toward a specific industry. The application would > probably be used by office personnel and not by the public at large. So > most customers would probably only have about 4 office people who would be > using it, maybe more but probably not much. Each customer should only be > able to manage their data. > > Does that clarify the question a little more? > > >
Yep, that's better. In fact I have deployed something very similar a year ago. You can consider using single code base with different databases for each of your customers. So when one goes to customer1.yourapp.com he'll login and have access only to his company data. Your virtual hosts customer*.yourapp.com will point to the same code, but you'll be able to use the appropriate db. This will reduce the possibility to customize the app per customer but it's not making it impossible. In comparison with the _everything in one db_ approach, the overall complexity of the application is reduced, as well as the risk that some bug in the code will show data from custumer1 to a user of custumer2. But only you know how sensitive the data is and other details. I think this way is reasonable for the small amount of users per customer you write about. Besides, you can always mix the things later and have your smaller clients use *.yourapp.com and put the bigger ones on their own servers. Hope that helps somehow. -- Regards, Martin Martinov http://mmartinov.com/
