Vor- und Nachteile von Views

[Antibiotik]

Hallo zusammen,

wenn ich den Anwendungen Daten aus der DB gebraucht habe, erstellte ich immer ein SQL Statement im Quellcode.

Ist es in Ordnung so oder sollte grundsätzlich über Views die Datenbankoperationen ausgeführt werden?

Ciao

Antibiotik

[robotto7831a]

Der Vorteil von Views ist, man kann diese sofort ändern bei einem Fehler und man muss keine neue Version von der Anwendung ausliefern.

Frank

[mme]

Das kommt ganz auf deine Applikationen an. Wir gehen auch immer direkt auf die Tabellen um uns den Overhead der Views zu sparen. (Laufzeittechnisch ist der minimal, aber verwaltungs- und entwicklungstechnisch würde es bei uns viel ausmachen. Wir hatten das mal überlegt, die wichtigen Sachen auch schon "vorzujoinen" hätten dann aber 4-5 mal soviele Views wie Tabellen und keiner wüsste mehr was eigentlich wofür...).

Dafür sind unsere Anwendungen sehr pflegeleicht durch die Objektorientierung. Dadurch das wir sehr gut gekapselt haben, müssen wir wenn wir im DB-Modell was ändern auch nur an einer Stelle in der Applikation was ändern.

Währe dies nicht gegeben könnte es aber auch bei uns sinnvoll sein immer über Views zu gehen....

Grüße mme

[The_red_one]

Views sind auch gerade dann sinnvoll, wenn mehrere User/ Apllikationen usw. die gleiche Abfrage brauchen. Dann machts auch Sinn einen View zu erstellen.

[bigpoint]

Hallo zusammen,

wenn ich den Anwendungen Daten aus der DB gebraucht habe, erstellte ich immer ein SQL Statement im Quellcode.

Ist es in Ordnung so oder sollte grundsätzlich über Views die Datenbankoperationen ausgeführt werden?

Ciao

Antibiotik

warum Views ??

Prozeduren oder Funktionen sind da besser.

[kingofbrain]

@The_red_one und bigpoint

Könntet Ihr Eure Aussagen bitte mit Gründen stützen? Mich interessiert das Thema auch, und ich habe auch schon öfter überlegt, ob Views nicht einfach ein Überbleibsel der Zeit sind und heute durch Persistenzschichten ersetzt werden.

Deshalb wären Argumente für Eure Thesen sehr hilfreich.

Danke schonmal.

Peter

[bigpoint]

@The_red_one und bigpoint

Könntet Ihr Eure Aussagen bitte mit Gründen stützen? Mich interessiert das Thema auch, und ich habe auch schon öfter überlegt, ob Views nicht einfach ein Überbleibsel der Zeit sind und heute durch Persistenzschichten ersetzt werden.

Deshalb wären Argumente für Eure Thesen sehr hilfreich.

Danke schonmal.

Peter

Klar kann ich.

Also aus zwei Gründen:

1. so wie bei Views leichte Änderung Möglichkeiten

2. Prozeduren und Funktionen sind erheblich schneller als

nackte SQL - Stetmens die noch mit Hilfe von was weis ich

welchem Treiber an Server geleitet sind.

[BenjieAul]

Irgendwie stehe ich total auf dem Schlauch

Was sind denn nochmal Views?

Prozeduren, etc, kenne ich, aber Views ahbe ich vergessen was das ist. KAnn mir jemand erklären ? :confused:

[kLeiner_HobBes]

VIEWs sind, soweit ich weiß, SELECTs, die hinter dem Viewnamen "versteckt" werden. Nach dem Motto

CREATE VIEW komplex AS

SELECT a.bla, a.blubb, b.und, b.so, a.weiter FROM tabelle1 a, tabelle2 b

WHERE a.id = b.id AND b.so > 500 ORDER BY a.bla

...

Danach machst du nur noch einen "SELECT * FROM komplex" und hast das Ergebnis. Du kannst sogar unter bestimmten Umständen in VIEWs einfügen, woran ich mich aber nicht unbedingt gewöhnen würde, da es 1. sehr eingeschränkt nur geht (bei nem JOIN zum Beispiel gehts nimmer) und 2. Stored Procedures da wohl besser sind.

HTH

[Antibiotik]

hallo,

dein schmeiß ich gleich die nächste Frage rein.

Was sind Proceduren bzw. Stored Proceduren?

Ciao

Antibiotik

[bmg4ever]

views:

- auf dem server liegende Select querys (meist mit joins zum zusammenfügen von tabellen), deren result unter einem Tabellenaliasnamen wie eine normale tabelle abgerufen werden kann.

stored procedures:

- prozeduren, wie aus gängigen programmiersprachen bekannt (oder für unsere C-nutzer "void-functions"), die aber nicht in eine lokales programm eingebunden sind, sondern auf dem Datenbankserver liegen und die Datenbank beim aufruf entsprechend dem quellcode auseinander und wieder zusammen dröseln.

kurz: es ist also auf dem server liegender quellcode in einer programmiersprache, der auf die datenbank losgelassen wird

korrigiert mich bitte, wenn ich was falsches gesagt hab. ich bin ja auch erst seit 4 monaten dabei

[kLeiner_HobBes]

zu stored procedures:

Es ist eigentlich SQL, was in einer stored procedure drin ist, allerdings gibt es nun auch Dinge, wie IF-Abfragen etc. Und s.p. sind für die DB gedacht, ist also keine eierlegende Wollmilchsau. Und ob man von Quellcode reden kann .. ich weiß net. Aber das ist wohl sehr sophistisch gedacht

[BenjieAul]

bedanke mich bei euch=)

Hab ich wieder was gelernt =)

thx @ all=)

[FinalFantasy]

Kann man die Views eigentlich in MySQL im PHPmyAdmin verwalten?

Bzw. kann man in MySQL Proceduren anlegen/erstellen? Ich bin zur Zeit auch gerade an einem kleinen Projekt und habe SQL-Abfragen mehrfach im Quelltext, was Änderungsanfällig ist, und mir deshalb auch schon überlegt auf Views oder Proceduren umzusteigen.

Ich weiss nur gar nicht, ob das in MySQL überhaupt möglich ist.

[FinalFantasy]

Hab grad ein bisschen nachgeforscht:

Views gibts erst ab MySQL 5.01 und Procedures gibts erst ab MySQL 5.0.

Auf meine Webspace ist 3.28.xx...

Alternative Vorschläge?

[mme]

Ja, kapseln im Programm

[Nachtgeist]

Views sind z.B. gut um fuer eine Anwendung (Frontend, Reportgenerator, whatever) eine vereinfachte Version einer komplexen Datenbankstruktur (z.B. Warenwirtschaftssystem) zur Verfuegung zu stellen, die ausserdem Strukturaenderungen in der grundlegenden Datenbank kaskadiert, so das man die Anwendung nicht jedesmal aendern muss.

Updates lassen sich dann entweder ueber Trigger auf den Views (sehr bequem, feine Sache ) oder ueber der Anwendung als Funktionen bereitgestellte stored procedures umsetzen.

Wenn deine Datenbank keine Views zur Verfuegung stellt, koenntest du schauen, ob das PHP (oder womit du das auch immer auf dem Webserver machen willst) SQLite unterstuetzt. Das kann Views und - eingeschraenkt - auch Trigger.

[FinalFantasy]

Hm, darauf wirds dann wohl rauslaufen...

[Jasper]

2. Prozeduren und Funktionen sind erheblich schneller als

nackte SQL - Stetmens die noch mit Hilfe von was weis ich

welchem Treiber an Server geleitet sind.

die begründung dazu würde mich interessieren; zusammen mit der angabe, bei welchem dbms das so sein soll.

-j

[Jasper]

Views sind z.B. gut um fuer eine Anwendung (Frontend, Reportgenerator, whatever) eine vereinfachte Version einer komplexen Datenbankstruktur (z.B. Warenwirtschaftssystem) zur Verfuegung zu stellen, die ausserdem Strukturaenderungen in der grundlegenden Datenbank kaskadiert, so das man die Anwendung nicht jedesmal aendern muss.

ich sehe views vor allem dazu, um ein subset der daten zur verfügung zu stellen. bspw. kann ich einen view auf eine tabelle mit personaldaten legen und sensitive daten (gehalt) aus dem view rauslassen. der nutzer bekommt nur rechte auf den view, nicht auf die tabelle.

-j

[Nachtgeist]

Ein weiterer guter Anwendungszweck fuer Views...

[bigpoint]

die begründung dazu würde mich interessieren; zusammen mit der angabe, bei welchem dbms das so sein soll.

-j

allem die Funktionen und Prozeduren Unterstützen

[Jasper]

allem die Funktionen und Prozeduren Unterstützen

zumindest bei oracle ist die aussage "Prozeduren und Funktionen sind erheblich schneller als nackte SQL" nicht korrekt. eine prozedur oder funktion, die die gleiche funktionalität wie ein view hat, ist nicht schneller als plain sql. sql ist die basis, alles andere setzt darauf auf.

daher kann nichts schneller sein als plain sql.

-j

[bigpoint]

zumindest bei oracle ist die aussage "Prozeduren und Funktionen sind erheblich schneller als nackte SQL" nicht korrekt. eine prozedur oder funktion, die die gleiche funktionalität wie ein view hat, ist nicht schneller als plain sql. sql ist die basis, alles andere setzt darauf auf.

daher kann nichts schneller sein als plain sql.

-j

Doch, schon über Ausführung Plan was gehört ??

Bei Prozeduren und Funktionen auch bei Oracle wird eben der Ausführung Plan nur einmal von DB erstellt und zwar bei anlegen bzw. aktualisieren.

Bei nacktem SQL muss der Arme DB bei jedem Ausführung es tun.

Schon das ist ein Grund warum SP oder Funktionen schneller sind.

[Nachtgeist]

Ein Execution Plan wird auf Statement-Ebene definiert und das fuer jede Datenbankabfrage.

Ob die Abfrage jetzt ueber eine SP, einen View oder einem SELECT abgesetzt wird ist dabei egal.

Desweiteren kann sich der Execution Plan von Zeit zu Zeit aendern. (Ausser die Datenbank dahinter aendert sich nicht.) Auch bei Prozeduren.

Das der Execution Plan bei Views oder nacktem SQL jedesmal neu erstellt wird stimmt nicht. Der wird gecached und bei identischen Abfragen erneut verwendet. Genau wie im Fall einer SP.

Kannst du deine Aussage, dass Prozeduren generell schneller sind, als Views (und sei es nur bei einem besimmten RDBMS) sinnvoll belegen?