On Fri, May 20, 2011 at 7:55 AM, Michael Giarlo <michael.gia...@gmail.com> wrote: > I suspect we would go with #3
definitely #3. it's called multi-tenancy, and it's a mess to add to an existing application, much better to design from the start. for the most part, it means most of your tables will need a 'tenant' foreign key. I usually also add a decorator that adds the tenant to the request object (much like the @login_required and friends set request.user), and most of the queries inside the views start like request.tenant.book_set.filter..... instead of the usual Book.objects.filter..... google around for multitenancy, you'll find lots of similar cases. the most repeated discussion is if you should use one DB per tenant, or a single DB for everybody. some people argue that a DB per tenant provides some 'poor man sharding'; but most conclude that the most scalable way is a single DB for everybody. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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.
