Re: OffTopic: SQL-Fragen

[daniel _at__ roedding.de (Daniel Roedding)]

Hallo und guten Morgen!

Heiko Jansen schrieb:
> At 16:06 14.06.00, you wrote:
[ autsch - hatten wir da nicht gerade einen Thread "Zitieren von/in
  elektronischen Medien? :-) ]
> >Zum einen: Worin besteht das "View-Update-Problem"?
> ? Leider keine Ahnung.

Vielleicht ist die Problematik gemeint, daß datenbanktechnische Views in
der Regel "read-only" sind.

Exkurs in die Datenbanktechnik: Views ermöglichen es, "Pseudo-Tabellen"
zu erstellen, die aus bestehenden Daten in einer (administrationsabhängig
mehr oder weniger) sinnfällig definierten Anordnung bestehen. Beispiel:

Tabelle "Benutzer" enthält ein paar Benutzer-Eckdaten, z. B. Name,
Straße, Ort und eine ID. Tabelle "Ausleihe" enthält eine Liste mit ID,
Titel und Datum. Dann kann man, um die Generierung menschenverständlicher
Listen zu vereinfachen, einen View generieren, der aus den Feldern
Name, Titel, Datum besteht und bei dem das Kriterium für das Zusammenfügen
der beiden Tabellen darin besteht, daß die ID's der jeweils "passenden"
Tabellenzeilen die Gleichheit der ID's ist.

Oder in (ORACLE-)SQL, die Tabellenfelder sind natürlich nur beispielhaft
und für die Realität nicht ausreichend:

	create table Benutzer (
	  ID		number primary key,
	  Name		varchar2(80),
	  Strasse	varchar2(80),
	  Ort		varchar2(80)
	);

	create table Ausleihe (
	  BenutzerID	number references Benutzer(ID),
	  Titel		varchar2(80),
	  Datum		date
	);

	create view Leihliste as
	  select B.Name as Name,A.Titel as Titel,A.Datum as Datum
	    from Ausleihe A,Benutzer B where A.BenutzerID=B.ID;


Zurück zum Problem "View-Update": Der View "Leihliste", der unten generiert
wurde, kann wie eine normale Tabelle ausgelesen werden. D. h. ein "select"-
Statement funktioniert genauso wie auf einer "normalen" Tabelle. Nicht
möglich ist aber ein "insert" oder "update", bzw. bei einigen Datenbanken
sind einige wenige Konstellationen möglich. In der Regel muß man aber erst
einmal davon ausgehen, daß Views potentiell "read-only" sind, was sich
prinzipbedingt auch schon oben leicht erklärt: Zwischen den beiden Ausgangs-
tabellen gibt es eine relationale Abhängigkeit über die ID des Benutzers,
sonst würde das ganze Spielchen ja überhaupt keinen Sinn machen. Wenn
nun ein neuer Datensatz im View angelegt werden sollte müßte selbiger
wissen, daß zunächst ein Benutzer anzulegen ist und dann erst der Ausleihsatz
geschrieben werden kann. Diese Vorgehensweise definiert sich aber nicht
eindeutig über die "where"-Klausel im "create view ... select"-Statement
oben, so daß die Datenbank nicht wissen kann wie sie zu verfahren hat. Also
geht es nicht. Es würde ohnehin bei mehr als zwei involvierten Tabellen
und komplexeren Abfrageklauseln schnell noch viel übler werden als in obigem
Beispiel.

Soviel zu nächtlicher Stunde mal wieder von der Softwarefront von einem
Menschen, der mal wieder den Feierabend verpaßt hat... :-)

Viele Grüße,
Daniel Rödding

-- 
Daniel Roedding                                       phone: +49 5252 9838 0
daniel _at__ roedding.de                                      fax: +49 5252 9838 20