Thanks for your reply Justin, I'd like to avoid having multiple tenants in the same database, I feel multi-database is easier to scale, and simpler in a code maintenance sense. It does required to run database migrations once per tenant, but I still see it as the better solution.
One solution I saw is having a schema per tenant: http://tidbids.posterous.com/saas-with-django-and-postgresql-schemas and another is a pandora's box: https://github.com/gregmuellegger/django-pandora I haven't tried any of these, but they seem like they might be solutions for this problem. On Jan 5, 12:30 pm, Justin <jlmurph...@gmail.com> wrote: > Have you looked at the Sites framework? You could have multiple > tenants using one database and use a ForeingKey to a Site object to > structure the data. This will result in more complex queries, but > might be less of a cost than the maintenance issues (see below). > > If you continue reading that IBM document, the "Database > Considerations" section strongly urges you not to pursue the multiple- > tenants, multiple-databases model due to the inherent maintenance > overhead. > > http://www.ibm.com/developerworks/cloud/library/cl-multitenantsaas/#N... > > If you end up finding a good solution to this hairy problem, please > post it. I'd be interested to see what you come up with. > > -Justin -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
