>I've always though that this particular -- and common -- use case >should be delegated to the DB level using one of the many excellent >replication/distribution tools for your database. For example, you >could easily do read distribution with pg_pool or sqlrelay, and it >would be transparent to Django. I don't see a good reason to tackle >replication in Django itself as that's more or less a solved problem.
Beside the fact that most of those "excellent" after-market replication solutions just plain suck ;-) - there are very good reasons to have data-driven distribution. This might be controlled by tables - some tables living on different databases or servers - or by content. Like data from older years living in other databases or on other servers. So even if you get those replication solutions to work reliable (which I never was able to do with sqlrelay - the client goes bozo if the server has problems), you _can't_ do those data-driven distribution with after-market tools. This has to be done on application level. A scenario from my work: a ERP system which produces loads of accounting data. Older data is moved to some external database, because it would put too much load on the active database. Then there are special data aggregates that are stored in another database for faster queries - they are specially prepared. So the application needs to access three databases simultaniously. And in large installations, those databases will be even run on different servers. So, yes, I do think it would be very useful for Django to be able to access multiple databases via it's ORM. Actually I have already exactly that requirement in some Django project: while trying to build a admin interface for my db-based nameserver and db-based mail-system, I have the problem that DNS and Mail are handled by different databases, so I am blocked on that project currently, as Django won't let me work with both databases ... bye, Georg
