Was sind Views, Stored Procedures und Trigger

[lospitas]

Hallo zusammen,

ich hab mal danach gegoogled und verstehe nicht ganz was das genau ist.

kann mir das mal bitte jmd in eigenen leichten Sätzen erklären büdde :-(

Danke schon mal im voraus.

Gruß,

lospitas

[dbwizard]

Sicht (Datenbank)

Gespeicherte Prozedur

Datenbanktrigger

Gruss

[allesweg]

View

Stored Procedure

Trigger

[lilith2k3]

Dann verrate uns in kurzen Sätze, was Du bisher nicht verstehst, dann erklären wir Dir das gerne

[splasch]

Ich denke es geht darum wann und wieso man ein Zum Beispiel eine View einsetzt.

Im Grunde ist ja eine View so zu verstehen das es sich dabei um eine Tabele handelt die aus einer Aufwendigen Select abfrage enstanden ist. (Zb. ein Select das übere mehre Tabeln läuft und grupiert wird)

Wenn ich es richtig verstanden hab ist der Vorteil nun das man das Erbniss leicht und schnell immer wieder abfragen kann. Desweitern auch weiter Filtern in der Abfrage.

Also dann eben nach bestimmten Sachen drin suchen oder nur Teile davon ausgeben.

Sorry ich bin nicht so gut in Datenbanken aber ich denke das sollte es umgefähr grob zusammen gefasst sein.

Oder wann würdet ihr ein View verwenden und Warum?

Mfg Splasch

Bearbeitet 7. März 2012 von splasch

[dr.dimitri]

Wenn ich es richtig verstanden hab ist der Vorteil nun das man das Erbniss leicht und schnell immer wieder abfragen kann. Desweitern auch weiter Filtern in der Abfrage.

Eine VIEW ist nur eine weitere Abstraktion einer Abfrage. Da läuft nichts schneller, es wird nur Komplexität verborgen. Das ist auch der erste Punkt warum man eine View verwendet. Der zweite Punkt wären Berechtigungen. Ich stelle eine View zur Verfügung, die nur bestimmte Daten selektiert. Anschließend vergebe ich die Berechtigungen, damit ein bestimmter Benutzerkreis diese View lesen darf.

Ein dreitter Punkt wäre, dass Programme hin und wieder eine Tabelle benötigen um daraus zu lesen. Habe ich keine Tabelle in der geeigneten Form, kann ich dem Programm evtl. auch eine VIEW unterjubel, die sich nach außen hin wie eine echte Tabelle verhält (solange ich dort nichts ändern möchte).

Mit Geschwindigkeit hat eine VIEW rein gar nichts zu tun. Sie ist nicht schneller oder langsamer, als wenn ich das zugrundeliegende SQL direkt ausführen würde.

[streffin]

mmmhm Prinzipiell hast du recht dimitry, aber zumindest unter MSSQL bringt eine View unter betimmten Umständen durchaus etwas Performance.

Beispiel wäre, dass gefilterte Views parametisiert werden, und der Execution Plan dann auch für komplexe Querys eher gechached und gefunden wird und so Geschichten. Kann also durchaus auch Performance relevant sein.

Wenn ich jetzt noch Tabellen Partitionierung mit reindenk, dann gibt das langsam richtig lustige Konstellationen, und eventuell auch deutliche Performance unterschiede. Von lock escalations mal ganz zu schweigen....

Anwendungsfall ist häufig, dass man die View mit WITH CHECK OPTION anlegt und damit db Usern Rechte auf bestimmte Teilbereiche einer Tabelle einräumt, während sie auf anderen nicht zugreifen können.

Beispielsweise

 SELECT * FROM tabelle WHERE country = 'de' 

sowas in der Richtung.

Wenn ich das als View mit with check option anlege, fängt das auch Inserts ab, die nicht mit der Where Bedingung übereinstimmen.

Es führt eventuell für so eine grundsätzliche Verständnissfrage zu weit, und ich geh da jetzt bei Gott auch nicht auf alles ein, aber Views können schon einiges mehr als nur das zugrundeliegende Query ausführen.

War jetzt gesprochen für MSSQL. Oracle, DB2, Postgree und was es sonst noch alles gibt, ist da jeweils wieder ein eigenes Thema für sich

Gruß

Sven

Bearbeitet 14. März 2012 von streffin