ein sichers Statement ist z.B. Erstens q und nicht qq, damit man sich selbst davor schützt, unbemerkt Variablen im Statement zu aufzulösen/interpretieren. Der 2. Punkt ist, daß man die Variablen dem Treiber übermittelt. Denn wenn man sie in den Text des SQL einfügt, dann ist das unsicher gegenüber SQL-Injektion.

Noch eins:

Prinzipiell kann man in jeder Programmiersprache sicher programmieren. Es ist nur die Frage, wie weit man von der Programmiersprache dabei unterstützt wird und wieviel Zeit man dafür investieren kann. Wenn man in Perl den Willen nicht hat, kann man auch in Perl den unsichersten Code aller Zeiten programmieren. Jedoch ist es so, wenn man sich die Beschreibung des Modules DBI einmal durchgelesen hat und diese auch begriffen hat, daß man dann weiß, wie man es macht und auch wie man es nicht macht.

Das Problem ist wahrscheinlich, daß Dein Professor nicht informiert ist. Auch wenn jemand Professor ist, heißt das noch lange nicht, daß er alles weiß. Das ist einfach so und auch menschlich. Nur nützt Dir das nichts. Er wird nicht zulassen, daß Du ihn belehrst, meistens jedenfalls. Das Schulsystem beschreibt den Weg genau anders herum. Also gewöhne Dir einen erstklassigen Programmierstiel an. Dabei helfen Dir hier alle und sieh zu, wie Du das Problem mit Deinem Professor elegant umschiffen kannst. Wenn Du Dein Studium geschafft hast, kannst Du ihm ja dann mal erzählen, wie schwer es war, nicht mit dem besten Werkzeug arbeiten zu dürfen.

Der Aufruf der stored procedure erfolgt am Ende auch nur mit SQL und die Übermittlung der Daten dahin hat genau den gleichen Weg, wie auch ein simples SQL-Statement. Nur kennt die Datenbank die SQL-Anweisungen schon durch die stored procedure. Also kann man diese nicht mehr negativ beeinflussen, sorndern nur noch parametrieren. Das gleiche passiert, wenn man, wie ich oben geschrieben habe, das SQL-Statement von den Daten konsequent trennt. Auch dann ist das Statement der Datenbank schon bekannt und von ihr geprüft/geparst, läßt sich nicht mehr verändern und wird nur noch parametrisiert.

Wenn man keine Daten zurückerwartet, dann ist do die geeignete Methode, ansonsten wird das Statement mit den Platzhaltern ? mit der Methode prepare übertragen und die Daten folgen dann beim execute. Gerade beim insert hat das Vorteile, weil man auch auf ein prepare mehrere executes ausführen kann und dem execute jedes Mal neue Daten übermittelt. Die Datenbank braucht dann nicht jedes Mal das Statement parsen. Es liegt so bereits fertig vor, verlinkt über das Statementhandle, was das prepare zurückgibt. Schiebt man also mehrere Datensätze über ein Statement oder erwartet man Daten zurück, ist do nicht geeignet. Aber mache nicht alles mit prepare, execute, nur weil es so auch geht. Das do hat seine Berechtigung.

$h->func(@func_arguments, $func_name);
hat nichts (oder nicht direkt) mit stored procedures zu tun. Es handelt sich hier um Funktionen des Treibers (DBD::irgendwas), die nicht portabel sind. So könnte ein Treiber eine Datenbankfunktion unterstützen, mit dem man z.B. Mails vom Datenbankserver aus versenden kann. Und weil so etwas nicht unbedingt jede Datenbank unterstützen muß, gehört es in die Kategorie der nicht portablen Funktionen.\n\n

<!--EDIT|steffenw|1137943151-->

Quote

Gerade beim insert hat das Vorteile, weil man auch auf ein prepare mehrere executes ausführen kann und dem execute jedes Mal neue Daten übermittelt. Die Datenbank braucht dann nicht jedes Mal das Statement parsen. Es liegt so bereits fertig vor, verlinkt über das Statementhandle, was das prepare zurückgibt.

Gerade bei Postgres bringt dir prepare+execute keine Vorteile in der Geschwindigkeit. Aber das nur am Rande :)\n\n

<!--EDIT|nepos|1137943726-->

... bei MS-SQL auch nicht, aber programmiere portabel.

Nein, also daß Proffessoren keine Götter sind. Ist mir schon klar. Klarer als 99% meiner Komilitonen!!! :-) Ich habe vor dem Studium schon als Programmierer gearbeitet, und fühle mich an der Fachhoschule schon ein bischen wie in Absurdistan! Ich würde gerne nur eine einigermaßen unabhängige Beurteilung der verschiedenen Technologien.

Es ist im Moment so, daß man nicht nur an der FH sondern auch auf der Arbeit Probleme bekommt, wenn man Datenbank-Anbindungen über Perl realisieren möchte. In diesem Zusammenhang wäre es sicher hilfreich wenn man endlich mal genaueres über Perl6 erfahren könnte, und nicht erst durch Informationen, die man sich selbst beschafft. Einfach so, daß man endlich erfährt wo der Hase hinläuft.

Gruss Christian

Ich weiß nicht, was Du von Perl 6 erwartest. Perl 6 ist einfach nur eine Programmiersprache einer neuen Generation mit einem neuartigen Bytecodeinterpreter, der sich auch schon bei Objeken perfekt auskennt. DBI ist ausgereift, da haben andere Programmiersprachen eher noch Nachholebedarf. Soweit ich weiß, ist die Java-Datenbankanbindung nur von DBI abgekupfert.

Es gibt hier ein Thema "Perl-Workshop", dort ist das Programm verlinkt. Dort geht es auch um Perl 6.\n\n

<!--EDIT|steffenw|1137949487-->

Wo bekommt man auf der Arbeit Probleme wenn man mit Perl auf eine Datenbank zugreifen will?? Wie Steffen schon geschrieben hat, ist es mit Perl wesentlich einfacher und - wenn man weiß was man macht - sicherer als in vielen anderen Sprachen...

Wenn Dich Perl6 mehr interessiert:
http://www.perl.com/pub/a/2006/01/12/what_is_perl_6.html
http://dev.perl.org/perl6

Zunächst will ich erst mal sagen, daß ich Perl nicht niedermachen will!!!!!!!
Aber in meiner Umgebung ist einzig der Perl-Stammtisch in Frankfurt wo ich positives über Perl höre. Aber man muß auch auf den Rest der Welt hören. Was mir besonders Sorge macht, ist die Tatsache, daß ich auch von den Laboringeneuren meiner Fachhochschule zu hören bekomme, daß ich dringenst meinen Schwerpunkt auf eine andere Sprache als Perl setzten sollte! Und die Laboringenure sind durchaus Leute, die nicht nur im Elfenbeinturm Hochschule leben, sondern die meiste Zeit in der Wirtschaft sind! Begründet wird das damit, daß Perl nicht weiter entwickelt wird, was natürlich nicht stimmt. Aber solche Einschätzungen sind WICHTIG!!! Was nützt das,wenn Larry Wall und Co. die tollste Sprache entwickeln, wenn die Welt davon nichts mitbekommt, oder den Eindruck hat, da würde nur irgend ein Compiler-Kunstwerk geschaffen, das supergenial ist aber keinen Nutzen hat.

Wenn ich von Perl6 spreche, dann im Zusammenhang mit PR für Perl. Denn, wenn ich mit Leuten spreche, die etwas besser informiert sind, über die Entwicklung von Perl, dann erzählen diese, da würde eine Programmiersprache enstehen, die die letzen Reste (bzw. Fesseln) von strukturierter Programmierung abwirft. So etwas was theoretische Mathematiker und Informatiker immer schon haben wollten, so etwas wie Brainfuck, und etwas was nie fertig wird. ( ich zitiere, das wurde mir so gesagt, also antwortet mir bitte nicht, daß Brainfuck etwas völlig anderes ist. Das ist mir schon klar. Manche Leute mögen es halt zu polarisieren, ich aber auch ;-) ).

Auch auf meinem Arbeitsplatz ernte ich im allgemeinen nur ein schiefes lächeln, wenn ich vorschlage etwas in Perl zu realisieren. Ich kann mich dann meistens schon durchsetzten, weil ich meine Aufgaben dann sehr schnell umsetzen kann. Sonst dürft ich hier nichts mit Perl machen!

Was ich wirklich wissen wollte war, wo bekomme ich Informationen, über die Schwachstellen der versch. Web-Technologien? Wo kann man am besten z.B. mit Exploids was erreichen, wo ist was besonders anfällig. Denn man muß schon auch selbstkritisch sein!

Gruss Christian\n\n

<!--EDIT|pug|1138028811-->

Nebenbei: MS verwendet zum Testen recht viel Perl und unterstuetzen deshalb auch Activestate finanziell. MS liefert Perl auch in den Windows-Ressourcekits aus (allerdings ohne Support), und die ausgabe von ftype /? ist auch immer recht interessant (hier z.B. unter WinXP)

(da fehlen zwar anfuehrungszeichen um "%1" herum, aber immerhin...)