Tabellen "synchronisieren"

[Passer]

Hallo,

ich habe da ein kleines Problem mit einem Vorhaben.
Zunächst einmal die Ausgangssituation:
Tabelle1: Prim1, Prim2 (2 Primärschlüssel, keine künstlichen Indizes)
Tabelle2: Prim1,Prim2, Value (die selben Primärschlüssel, zwecks Identifikation, keine künstlichen Indizes)

Vorhaben:
Tabelle 1 und 2 sollen (in Abständen) synchronisiert werden. d.h. kommt eine (Prim1, Prim2) Kombination in 1 dazu, soll diese auch in 2 hinzugefügt werden.
Wird eine (Prim1, Prim2) Kombination in 1 gelöscht, soll diese auch in 2 gelöscht werden.

Das ganze soll möglichst mittels SQL-Syntax geschehen, da ich Implementierungsunabängig bleiben möchte


Hat jemand ne Idee?

 

[klanawagna]

Trigger setzen für T1 -> der in T2 schreibt.

EDIT:
Sorry, hab wenig zeit gehabt um zu antworten, hier etwas umfangreicher:

CREATE
TRIGGER sync AFTER INSERT
ON TABELLE1 FOR EACH ROW INSERT INTO TABELLE2

habs gerade nicht genau im Kopf, aber die MySQL-Seite sollte dir dabei helfen!


MYSQL - Trigger

lg!

 

[Yaslaw]

Zuerst: Was für eine Datenbank? wenn MySQL, dann ist der vorgeschlagene Trigger eine Idee.

 

[klanawagna]

Soweit ich weis, ist der Trigger auch für Postgres anwendbar. Hauptsache SQL

 

[fassy]

Trigger gehn auch in ORACLE und anderen RDBMS, nur haben i.d.R. alle eine andere Syntax

 

[Yaslaw]

Soweit ich weis, ist der Trigger auch für Postgres anwendbar. Hauptsache SQL

Mutige Beweislage....

Trigger sind sehr DBMS abhängig. Viele unterstützen sie, aber überall verschieden.
Trigger haben selten etwas mit Standart-SQL zu tun sondern eher mit der DBMS-Eigenen Programmiersprachen. Es sind Scripte, keine Statements.

 

[klanawagna]

Zum Beweis:

CREATE TRIGGER insert_price_change AFTER INSERT OR DELETE OR UPDATE ON stock
  FOR EACH ROW EXECUTE PROCEDURE insert_price_change();

das ist ein Postgresquery. ^^

 

[Yaslaw]

Ich beziehe mich eher auf dein Text "Haubtsache SQL".
Ich bezweifle nicht das Postgres Trigger kennt.
Und ja, es ist ein Query zum erstellen eines Triggers. Doch die Procedure insert_price_change() ist kein SQL, sondern eine Prozedure in der Postgres eigenen, SQL nahen Sprache.

Im Falle Oracle: PL/SQL ist kein SQL!

 

[dbwizard]

Zunächst einmal die Ausgangssituation:
Tabelle1: Prim1, Prim2 (2 Primärschlüssel, keine künstlichen Indizes)
Tabelle2: Prim1,Prim2, Value (die selben Primärschlüssel, zwecks Identifikation, keine künstlichen Indizes)

Hallo,

Zuerst mal eine Klarstellung : Prim1 und Prim2 ist ein zusammengesetzter PK, nicht war ? 2 verschiede Primärschlüssel in einer Tabelle kann es nicht geben, jedenfalls würd mich dies ziemlich überraschen...

Hallo,

Vorhaben:
Tabelle 1 und 2 sollen (in Abständen) synchronisiert werden. d.h. kommt eine (Prim1, Prim2) Kombination in 1 dazu, soll diese auch in 2 hinzugefügt werden.
Wird eine (Prim1, Prim2) Kombination in 1 gelöscht, soll diese auch in 2 gelöscht werden.

Das ganze soll möglichst mittels SQL-Syntax geschehen, da ich Implementierungsunabängig bleiben möchte

- Wenn du Zugang zur Update / Insert Logik hast, also dort, wo die Inserts / Updates geschrieben werden, so sollte das "synchronisieren" der Tabellen auch gleich dort gemacht werden : Wenn das Einfügen einer Row in eine Tabelle und das Aktualisieren der 2. Tabelle "Immer" zusammengehört, also aus Business-Sicht 1 Transaktion ist, warum sollte man dies aufspalten ?
- Wenn nicht, dann musst du Trigger verwenden, dies ist aber Datenbank - spezifisch, da wirst du um eine Spezialisierung nicht herumkommen

Aber vesuch es auf jefen Fall ohne Trigger zu lösen.


Gruss

 

[klanawagna]

Zuerst mal eine Klarstellung : Prim1 und Prim2 ist ein zusammengesetzter PK, nicht war ? 2 verschiede Primärschlüssel in einer Tabelle kann es nicht geben, jedenfalls würd mich dies ziemlich überraschen...

Doch, zusammengesetzte PK gibt es.

CREATE TABLE autor
(ISBN INT(11) NOT NULL,
VName VARCHAR(15) NOT NULL,
NName VARCHAR(15) NOT NULL,
PRIMARY KEY (ISBN, VName, NName)
);

- Wenn du Zugang zur Update / Insert Logik hast, also dort, wo die Inserts / Updates geschrieben werden, so sollte das "synchronisieren" der Tabellen auch gleich dort gemacht werden : Wenn das Einfügen einer Row in eine Tabelle und das Aktualisieren der 2. Tabelle "Immer" zusammengehört, also aus Business-Sicht 1 Transaktion ist, warum sollte man dies aufspalten ?
- Wenn nicht, dann musst du Trigger verwenden, dies ist aber Datenbank - spezifisch, da wirst du um eine Spezialisierung nicht herumkommen

Ich glaube mit Implementierungsunabhängig meint er die Sprache, nicht die Datenbank


lg!