Unfortunately one of our requirement is to use mySQL. So this wouldn't work with that correct?
To be honest at this moment I am not sure of pros & cons of using mySQl v/s postgres I will do some more research on that and see if switching to postgres SQL is an option. -Subodh On Fri, Jul 18, 2014 at 9:11 PM, carlos <[email protected]> wrote: > Hi, Subodh right now i find information for multi-tenant project in django > and see > this app, i never used only i read information for the future project. > > https://github.com/bernardopires/django-tenant-schemas > > maybe help you. > > Cheers > > > On Fri, Jul 18, 2014 at 6:56 PM, Mike Dewhirst <[email protected]> > wrote: >> >> On 19/07/2014 3:51 AM, Subodh Nijsure wrote: >>> >>> This is the first time I am trying to implement multi-tenant setup >>> under django and hence the question. >>> >>> Problem/Setup >>> - There are two companies signed up for service from portal I am >>> developing say CompanyA, CompanyB. >>> >>> - Each user with this setup is identified by unique email address, >>> users login using their email address and password. >>> >>> - CompanyA has following users >>> A-tech1 >>> A-tech2 >>> A-tech3 >>> >>> - CompanyB has following users >>> B-tech1 >>> B-tech2 >>> B-tech3 >>> >>> Requirements: >>> >>> 1. Data security/isolation: Technician A-tech1, A-tech2, A-tech3 >>> should only be able to view data associated with companyA. Same for >>> B-tech* technicians should only be able to see data from companyB. >>> >>> 2. Scalability: CompanyA, CompanyB might be of different sizes - >>> companyA might have 10 users. While CompanyB might have 10000s users >>> representing large customers. >>> 3. SLA: There might be different service level agreement with companyA >>> & companyB. >>> >>> >>> I think, it doesn't make sense to lump data related to companyA, companyB >>> into same database. >>> >>> Proposed Architecture Possibilities: >>> >>> Path 1: >>> - system will use one replicated database for >>> authentication/authorization >>> - When a company is registered within the system, 'Administrator' will >>> assign a company to specific database connection. And request will be >>> routed to correct database using database router, based on currently >>> logged in user. >>> >>> See https://docs.djangoproject.com/en/dev/topics/db/multi-db/ for >>> multi-db applications under django. >>> >>> Path 2: >>> >>> Do the url based routing c1.company.com , c2.company.com in apache >>> server setup and let apache configuraion refer to different wsgi.py >>> scripts to set proper values for DJANGO_SETTING_MODULE. And each >>> settings file points to different databases. >>> >>> Are either of these approaches (1 or 2) work better? >> >> >> Another possible approach (in Postgres) is to keep everything in the same >> database but segregate the private tables into different schemas. Normally >> in Postgres everything goes into the public schema and you deal with privacy >> using decorators and logic. But you could use non-public schemas as a >> different segregation level. I'm not sure how easy or otherwise that might >> be using Django. >> >> I have a similar if not identical privacy/segregation requirement which >> needs to be solved before I can advance from prototype to production. Hence >> I'm very interested in how you solve yours. Please share ... >> >> Mike >> >> >> >>> -Subodh >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/django-users. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-users/53C9C227.7020405%40dewhirst.com.au. >> >> For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/CAM-7rO3eWkc_ixxoxSK%3DMUXgKicy%2Bc0Uc1%2B4ugjPWecTrLrYFw%40mail.gmail.com. > > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CALr9Q3YeZ%2BkrRAvXPCK1oTQVoa-0b1OULdW4UxCfC7zj1D%2Bj%2Bg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
