From: | Peter Wullinger <some-mail-drop(at)gmx(dot)net> |
---|---|
To: | news200309(at)munition(dot)mailshell(dot)com |
Cc: | pgsql-de-allgemein(at)postgresql(dot)org |
Subject: | Re: Ausgesuchte Daten replizieren |
Date: | 2004-09-24 06:58:41 |
Message-ID: | 20040924065841.GA44970@peter.home.wul |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-de-allgemein |
In epistula a Ulrich Mietke, die horaque Fri, Sep 24, 2004 at 07:58:58AM +0200:
> Peter Wullinger schrieb:
> >
> > Was spricht gegen sowas wie:
> >
> > psql: ~# DROP TABLE export_daten;
> > psql: ~# SELECT <...>
> > INTO export_daten
> > FROM <...>
> > WHERE <...>
> >
> > % pg_dump --table export_daten
> >
> > Wäre wahrscheinlich der minimale Aufwand in deinem Fall.
> >
> Damit erfasse ich leider nicht die gelöschten Datensätze.
Okay, jetzt bin ich endgültig verwirrt ;-).
Vielleicht habe ich nur nicht so genau verstanden, was genau
in deinem Szenario implementiert werden muß.
Meine Interpretation war, daß du zwei PostgreSQL-Datenbanken hast,
wobei die eine die Backend-Datenbank mit allen Daten und die andere
die Frontend-Datenbank mit nur den notwendigen Daten für das
Content-Publishing ist.
Wenn die Tabellenstruktur 1:1 diesselbe ist, bietet sich vielleicht
eine "Replication"-Lösung für PostgreSQL an, wie z.B. slony an:
http://gborg.postgresql.org/project/slony1/projdisplay.php
Die kopieren dann nur die geänderten Daten.
Wenn sich aber die Frontend-Daten aus Queries der Backend-Daten
berechnen lassen, ist es vielleicht sinniger die Queries auf der
Backend-DB laufen zu lassen und selektiv in die Frontend-DB
einzuspielen. Je nach Szenario die effezientere oder aufwändigere
Lösung.
Gruß,
Peter
--
Man is born free, yet he is everywhere in chains.
-- Jean Jacques Rousseau
From | Date | Subject | |
---|---|---|---|
Next Message | Ulrich Mietke | 2004-09-24 11:18:19 | Re: Ausgesuchte Daten replizieren |
Previous Message | Ulrich Mietke | 2004-09-24 05:58:58 | Re: Ausgesuchte Daten replizieren |