On 2 July 2013 05:49, Mike Dewhirst wrote:
I read the sql-**createforeigntable<http://www.postgresql.org/docs/devel/static/sql-createforeigntable.html> page
and I think I know what a distributed database is versus a replicated
database. But I have no idea why I would choose one over the other. Can you
suggest?
On Monday, July 1, 2013 10:32:53 PM UTC+10, si...@2ndquadrant.com wrote:
On 1 July 2013 13:02, Mike Dewhirst wrote:
You can use direct access via "foreign tables" the name of the Postgres
distributed database feature.
http://www.postgresql.org/**docs/devel/static/sql-**
createforeigntable.html<http://www.postgresql.org/docs/devel/static/sql-createforeigntable.html>
SimonOn 1 July 2013 13:02, Mike Dewhirst wrote:
On 1/07/2013 9:35pm, Tom Evans wrote:
On Sun, Jun 30, 2013 at 11:24 PM, Mike Dewhirst <mi...@dewhirst.com.au>
wrote:
On Sun, Jun 30, 2013 at 11:24 PM, Mike Dewhirst <mi...@dewhirst.com.au>
wrote:
mulianto and Avraham
Thanks for your suggestions. Dumping data isn't the entire problem -
which
is this:
There will be an *ongoing* need to add new data from tables in one
database
to the same-named tables in another database on a remote machine. Two
of the
tables are in a m2m relationship.
Thanks for your suggestions. Dumping data isn't the entire problem -
which
is this:
There will be an *ongoing* need to add new data from tables in one
database
to the same-named tables in another database on a remote machine. Two
of the
tables are in a m2m relationship.
distributed database feature.
http://www.postgresql.org/**docs/devel/static/sql-**
createforeigntable.html<http://www.postgresql.org/docs/devel/static/sql-createforeigntable.html>
I read the sql-**createforeigntable<http://www.postgresql.org/docs/devel/static/sql-createforeigntable.html> page
and I think I know what a distributed database is versus a replicated
database. But I have no idea why I would choose one over the other. Can you
suggest?
required. Replication could be thought of as pre-cacheing the data you want
to see.
In any case, I'm 99% sure I should "refactor" (if that's the right word)
the reference tables out of the database into a separate database and get
to that data via a Django router.
Why take them out and then bring them back in? Why not leave where they arethe reference tables out of the database into a separate database and get
to that data via a Django router.
and copy elsewhere?
Not sure how I'll do that just yet but it has to come ahead of a
distribute/replicate solution.
--distribute/replicate solution.
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
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 django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.
