A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
we are decided to explore on SaaS, I went through one article explaining the data model for SaaS applications. we can have
1. separate database for each tenant,
2. shared database but separate for each tenant,
3. shared database, shared schema.
we are decided to go with 1st or 2nd approach. my problem is where we store common login credentials for all the tenants, and how can we identify which schema to use for the logged in user.
can any body suggest me with an appraoch to develop an application in SaaS with the above requirement?
While there are probably several ways to do this:
If you are selling to individual users, keep a central authentication registry or database that includes metadata such as DB servers and connection information. When the application accepts the login, it retrieves the appropriate information for the actual user's database, and connects to it for the rest of the session.
If you are selling to clients, where each client can have multiple users, give each client a unique URL (e.g. client.mySaaSapp.com), and store a map of the URL to database information in your central registry, and then have the application authentication use the client's database and keep all users within the client's database.
The question of whether to have one database per customer, one database for all with different schemas, etc depends on how you expect to deploy and manage the databases, and fulfill the customers.
Monday, March 03, 2008
What Dan said. Or, use the domain prefix as the name of the database. For example, client1.yourapp.com maps to the client1 database, etc.
The only slight flaw with these schemes is that it is possible to see who your clients are by speculating about domains. For example, I could guess that client2 used your service, then request client2.yourapp.com and see that I was right.
Most of the time, this won't be a problem, but if it is, then just use the central credentials idea, with maps to the actual database used.
>> The only slight flaw with these schemes is that it is possible to see who your clients are by speculating about domains. <<
You would then add another attribute to the customer table that tells you what their scheme name is. So "BigCorp" becomes "GOLD10"
Raises your support costs (tech support needs a translator), but makes it more difficult to mine your customer list by war-dialing the URLs.
Monday, March 03, 2008
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz