SAP the world's biggest ERP program uses the option #3 above. They can host many companies in one system (a system has only one database). Each company has a client number (3 digits). The login screen has four fields. 1. userid, 2. password 3. client# and 4. Language. In the data dictionary - that is the schema - SAP has a field named "mandt" (shortened german for client) in *every* table that houses user data, but not in tables used by the over all system. The clever thing their runtime does is translate all queries by adding a where clause to include the client number for tables that have the mandt field in them. This is important because users can program the system. Hence cross company data access is prevented. Do you plan to treat all your tenants identically?
I have not had a need to do this. I have worked with SAP schema for many years, I just thought you might get some ideas from this. On Apr 11, 12:57 pm, pbreit <pbreitenb...@gmail.com> wrote: > I'm not sure there are (m)any silver bullets. The three basic approaches are > 1) separate DBs, 2) separate tables and 3) shared > db/tables:http://msdn.microsoft.com/en-us/library/aa479086.aspx > > I don't know if there are an "silver bullets" for this so you might just > have to brute-force code it. If the app is fairly simple, just check who's > logged in and show the appropriate data. You might also research if Web2py's > "group" functionality would help. Sorry, this isn't too helpful.
