Geschwindigkeit von Views verbessern

[Sir Rufo]

Zitat:

Zitat von alzaimar

Neben Stored Procedures bieten sich auch Functions an. Rein konzeptionell würde ich Funktionen vorziehen, denn eine Funktion liefert ja etwas (z.B. eine Tabelle), während eine Prozedur etwas auslöst bzw. bewirkt.

ist das bei firebird so?

Wenn ich bei MySQL in einer function einen SELECT * FROM foo schreibe, dann meckert MySQL schon bei der Anlage der Function.
Bei einer Procedure funktioniert das.

[mkinzler]

Eine UDF ist meines Erachtens was anderes als eine SP.

[alzaimar]

Zitat:

Zitat von Sir Rufo

Zitat:

Zitat von alzaimar

...Rein konzeptionell würde ich Funktionen vorziehen, ...

ist das bei firebird so?

Ich verwende kein Firebird. Aber ein Konzept ist unabhängig vom RDMBS. Ich suche mir dann ein RDBMS, das meinem Konzept entspricht.

Zitat:

Zitat von Sir Rufo

Wenn ich bei MySQL...

MySQL zählt nicht. :mrgreen:

Zitat:

Zitat von Sir Rufo

...dann meckert MySQL schon bei der Anlage der Function.

Und zwar, deshalb. :zwinker:

Ich denke, man muss auch bei MySQL (wenn es denn das Konzept vorsieht) in einer Funktion einen Funktionstyp definieren (Zahl, String, Tabelle o.ö) und dem Resultat dann etwas zuweisen. Falls MySQL diesbezüglich eine Einschränkung hat, und z.B. nur generische Datentypen als Funktionstyp erlaubt, dann wäre das peinlich, aber nicht zu ändern.

Ich sprach im Übrigen von Konzepten. Eine Funktion berechnet etwas und liefert es zurück (oder transformiert oder was auch immmer), eine Prozedur nicht, die macht etwas. Das man in einer SP auch 'SELECT' schreiben kann, ändert nichts an diesem Paradigma.

[mkinzler]

Eine Funktion liefert aber einen Wert zurück und keine Datenmenge. Eine SP kann auch eine Datenmenge zurückliefern. Deshlab ist sie imho in diesem Fall besser geeignet.
In Pascal könnte man eine Funktion als Prozedur mit Rückgabe beschreiben, bei einem DBMS stecken da verschiedene Konzepte dahinter.

[alzaimar]

Zitat:

Zitat von mkinzler

Eine Funktion liefert aber einen Wert zurück und keine Datenmenge.

ich kenne UDF auch mit Datenmengen als Rückgabewert. PostGres und MSSQL sind solche Kandidaten. Andere RDBMS können das vielleicht nicht.

Ich meine jedoch, das (z.B.) Firebird eine Syntax à la

SQL-Code:

SELECT * FROM StoredProcedure (foo,bar)

erlaubt. Somit stopfen sie Dataset-UDF und Stored-Procedures unter einen Hut. Das kommt dann aufs Gleiche raus und ist ok.

Was ich gar nicht mag sind Stored Procedures, die man mit 'EXEC' aufruft, und die dann eine Ergebnismenge liefern. Wie soll man da denn Filtern bzw. das Ergebnis weiterverarbeiten?

[mkinzler]

Nein, das gezeigte ist eine SP. Eine UDF ist in FB in einer Hochsprache implementiert, eine SP (noch) ausschliesslich als SQL-Code. Eine UDF liefert deshalb auch nur Werte zurück, da sie ja eine Funktion in einer Dll/so ist.

SQL-Code:

Select Funktion( <Parameter> from ...

[Errraddicator]

Zitat:

Zitat von Elvis

Zitat:

Zitat von Errraddicator

Und zu der ständigen Aussage "Weg von Client/Server Technolige, wir ham 2009 nich 1990, mach dies, tu das".
Wie soll ich das denn bei einer PHP-Anwendung machen?

Sogar PHP wird Remoting-Möglichkeiten wie SOAP kennen. Falls du überhaupt einen Rich/Smart Client haben willst. Sieht mir eher nach einer Website aus.

Zitat:

Das ist doch prinzipbedingt eine C/S Anwendung, oder sehe ich das falsch?

Nö, nicht in dem Sinne, den ich meinte.
Ich bezog mich bei C/S darauf, dass dabei der User direkten Zugriff auf die DB hat, und man deshalb so abartige Vergewaltigungen von RDMS-Features und Serverhardware braucht, um sich gegen diese Zugriffe des Users abzusichern.
Deine PHP Page wird ja selbst Zugangskontrolle ausüben, also warum denn das ganze NOCHMAL innerhalb der DB machen?
Will heißen, du sorgst doch in dem PHP-Server schon dass User X nur Dinge sehen/machen darf, die er auch wirklich sehen/machen darf.
Warum willst du denn jetzt zusätzlich eine weitere Kontrolle einbauen, die dich dann immer und überall CPU-Zyklen, Speicher und vernünftige Querypläne kostet?

Richtig, es geht um eine Webseite.

Und falls es dem potenziellen Angreifer trotz div. Abfragen im PHP selbst, doch noch mal gelingen sollten den Schritt zur SQL-Injection oder vergleichbarem gehen zu können, möchte ich halt auch auf DB Seite so weit sein, dass er auch in dem Falle nicht in der Lage ist, eine komplette Benutzerliste z.B. auslesen zu können.

Das kann in meinem System (es sei denn ich habe was übersehen) nämlich keiner ausser dem Admin.
Deshalb ja auch dieser ganze Heck-Meck mit Views auf Views auf Tabellen und Co. :D

[Sir Rufo]

Zitat:

Zitat von mkinzler

Nein, das gezeigte ist eine SP. Eine UDF ist in FB in einer Hochsprache implementiert, eine SP (noch) ausschliesslich als SQL-Code. Eine UDF liefert deshalb auch nur Werte zurück, da sie ja eine Funktion in einer Dll/so ist.

SQL-Code:

Select Funktion( <Parameter> from ...

Sag ich doch :mrgreen:

Zitat:

Zitat von alzaimar

Was ich gar nicht mag sind Stored Procedures, die man mit 'EXEC' aufruft, und die dann eine Ergebnismenge liefern. Wie soll man da denn Filtern bzw. das Ergebnis weiterverarbeiten?

Eine SP kann die übergebenen Parameter verarbeiten und über die Parameter auch Werte wieder zurückgeben.
Gleichzeitig kann die SP auch einen Datenmenge liefern (wie oben erläutert).

Brauche ich nur die Parameter-Übergabe und die Datenmenge ist für mich uninteressant, dann führe ich diese mit ExecSQL aus.
Benötige ich auch die Datenmenge, dann öffne ich die SP mit OPEN.
Jetzt kann ich die Rückgabe-Parameter auslesen und auch das DataSet verarbeiten.

cu

Oliver