updateable views

[Hansa]

Hi,

ein View ist ja im Prinzip nichts anderes, als eine temporäre table, die die Basistabellen abbildet. Daß diese, so wie teilweise behauptet wird, nur eine spezielle Sicht auf die Daten ist, stimmt offensichtlich so auch nicht. Angeblich kann man da auch UPDATES oder INSERTS drauf machen. Hat einer so was schon mal gemacht ??? Es soll über Trigger laufen und ein (Zitat Borland) : "handy feature" von Interbase sein.

[Phoenix]

Views lassen sich nicht nur mit IB realisieren sondern auch mit gängigen anderen DBMS wie MS SQL Server / MSDE und auch Oracle.

Eine View ist vor allem dann nützlich, wenn man sehr häufig bestimmte Joins verwenden muss. Diese Joins werden dann nicht jedesmal komplett ausgeführt (manche DBMS brauchen da schon ne Weile für ) sondern diese 'Sicht' auf die Daten wird gecached.

Sofern der View einen (oder mehrere) inner Joins verwendet kannst Du freilich auch Updates darauf machen. Bei outer Joins klappt das logischerweise nicht mehr.

[Garby]

Hallo,

im Prinzip kann man einen View nur updaten, wenn nur eine Tabelle abgefragt wird.
In Oracle kann man dieses Verhalten mit einem "instead of" Trigger umgehen. D.h. der Trigger wird statt mitCreate or Replace Trigger TRIGGER_NAME before Insert on TABELLE mit Create or Replace Trigger TRIGGER_NAME instead of Insert on VIEW erzeugt.
In diesem Trigger kann man die Anweisungen dann auf die einzelnen Tabellen aufteilen.
In IB 6.0 ist das meines Wissens nicht möglich, vielleicht aber in der neuesten Version von Borland.

[Hansa]

Zitat von Garby:

im Prinzip kann man einen View nur updaten, wenn nur eine Tabelle abgefragt wird...

Die behaupten aber steif und fest, daß auch ein insert/updae nicht auf eine Tabelle beschränkt ist ! Sofern man Trigger benutzt. Und die btroffenen Spalten dürfen nicht als NOT NULL definiert sein. Hier das Borland Beispiel:

SQL-Code:

CREATE TABLE Table1 (
    ColA INTEGER NOT NULL,
    ColB VARCHAR(20),
    CONSTRAINT pk_table PRIMARY KEY(ColA)
);
CREATE TABLE Table2 (
    ColA INTEGER NOT NULL,
    ColC VARCHAR(20),
    CONSTRAINT fk_table2 FOREIGN KEY REFERENCES Table1(ColA)
);
CREATE VIEW TableView AS
    SELECT Table1.ColA, Table1.ColB, Table2.ColC
    FROM Table1, Table2
WHERE Table1.ColA = Table2.ColA;

CREATE TRIGGER TableView_Delete FOR TableView BEFORE DELETE AS
BEGIN
  DELETE FROM Table1
  WHERE ColA = OLD.ColA;
  DELETE FROM Table2
  WHERE ColA = OLD.ColA;
END;

CREATE TRIGGER TableView_Update FOR TableView BEFORE UPDATE AS
BEGIN
  UPDATE Table1
  SET ColB = NEW.ColB
  WHERE ColA = OLD.ColA;
  UPDATE Table2
  SET ColC = NEW.ColC
  WHERE ColA = OLD.ColA;
END;

CREATE TRIGGER TableView_Insert FOR TableView BEFORE INSERT AS
BEGIN
  INSERT INTO Table1 values (NEW.ColA,NEW.ColB);
  INSERT INTO Table2 values (NEW.ColA,NEW.ColC);
END;

Nur was wird da genau jetzt gemacht

[Garby]

Das ist eigentlich identisch wie in meinem Beispiel von Oracle, ausser dass man keinen eigenen Triggertyp benötigt.
Das ist natürlich OK wenn man nur Updates oder Deletes macht. Beim Insert kannst du immer nur Datensätze in beiden Tabellen gleichzeitig anlegen. Da nützt dir die 1:n Beziehung nichts mehr.

Was da passiert? In den Triggern für den View werden die entsprechenden Anweisungen für die beiden Tabellen separat ausgeführt. Das ist eigentlich alles.