# Tabellen "synchronisieren"



## Passer (10. Februar 2010)

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 (10. Februar 2010)

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 (10. Februar 2010)

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


----------



## klanawagna (10. Februar 2010)

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


----------



## fassy (10. Februar 2010)

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


----------



## Yaslaw (10. Februar 2010)

klanawagna hat gesagt.:


> 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 (10. Februar 2010)

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 (10. Februar 2010)

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 (11. Februar 2010)

Passer hat gesagt.:


> 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 (11. Februar 2010)

dbwizard hat gesagt.:


> 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!


----------



## dbwizard (11. Februar 2010)

klanawagna hat gesagt.:


> Doch, zusammengesetzte PK gibt es.
> 
> lg!





Ja, das weiss ich... So wie der OP es formuliert hat, sieht es aber nach 2 *separaten* PK's aus...dies wollte ich verifizieren, deswegen habe ich es als Frage gestellt...




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



Nein, er verweist explizit auf SQL, und dies ist im Falle von Triggern DB-abhängig , was die Implementierung betrifft.


Gruss


----------

