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-->