Are there common patterns people use for creating multi-tenanted applications using Django. The built in "sites" framework seems like an option. Are there other approaches people have had success with?
相关问题
- Django __str__ returned non-string (type NoneType)
- Django & Amazon SES SMTP. Cannot send email
- Django check user group permissions
- Django restrict pages to certain users
- UnicodeEncodeError with attach_file on EmailMessag
相关文章
- Profiling Django with PyCharm
- Why doesn't Django enforce my unique_together
- MultiValueDictKeyError in Django admin
- Django/Heroku: FATAL: too many connections for rol
- Django is sooo slow? errno 32 broken pipe? dcramer
- Django: Replacement for the default ManyToMany Wid
- Upgrading transaction.commit_manually() to Django
- UnicodeEncodeError when saving ImageField containi
Take a look at https://github.com/bcarneiro/django-tenant-schemas You'll only have one project instance and won't have to do many modifications in your code.
Using the sites framework goes a long way towards providing a security guarantee to the "tenants", assuming you give each site instance a unique table.
On the other hand, it'll be a big hassle if you have a small number of tenants and you'll waste a huge amount of server resources since you'll need at least one server process per customer even if they aren't using the system. If you have a large number of tenants it won't be quite as much hassle because you'll be forced to automate the solution regardless of your approach.
Putting a tenant foreign key in almost all your models will work just fine and Django's ORM makes it easy (easier?) to enforce security using custom managers. The drawback is performance if you start getting hammered with lots of users, because there's no easy way to scale up.
If you do need to scale, I think the best solution could be a combination of both approaches. Every model has a tenant foreignkey so databases can be shared but then you develop some mechanism at a higher level than Django to route customers into a site instance. This lets you put really big tenants on their own databases with resources properly tuned just for them (e.g. the proper number of mod_wsgi daemons, number of database connections, memcache pool properly sized, etc.) and smaller tenants share common resources.