Fallgruben und -stricke: (anfänger-)typische Fehler?

[Christoph Zurnieden]

Hallo zusammen,

das Archiv erschlug mich fast mit Hits, es scheint sie also zu geben.
Leider ist mir das wirklich zuviel, um das in angemessener Zeit anständig sortieren zu können (Der Archivserver hat schließlich so schon genug zu tun ;-), deshalb wende ich mich an euch direkt.

Gibt es so etwas wie typische (Anfänger-)Fehler in PHP und wie sehen die aus?
Vor allem interessieren mich sicherheitstechnisch relevante Fehlleistungen, weniger der typische Anfänger, der nicht in die FAQ geschaut hat.

Worum es eigentlich geht: woran erkennt der PHP-mäßig unbedarfte Chef, das er sich eine rechte Graupe eingehandelt hat. Wenn ich das einmal so brutal formulieren darf ;-)

Dies ist übrigens einer der Threads, wo das Pseudonym "linksetzer" durchaus nicht ungern gesehen würde ;-)

so short

Christoph Zurnieden

[Marc Reichelt]

Hi!

Gibt es so etwas wie typische (Anfänger-)Fehler in PHP und wie sehen die aus?

Also ein typisches Problem bei Anfängern fängt schon beim Installieren und Konfigurieren von PHP an.
Weiterhin gibt es unter anderem bei Neulingen das Problem, dass sie nicht GET- und POST-Variablen abfragen können (register_globals auf no gesetzt).
Mir fallen sicher noch ein paar ein... *g*

cu

Marc Reichelt || http://www.marcreichelt.de/

[Christoph Zurnieden]

Hallo,

Gibt es so etwas wie typische (Anfänger-)Fehler in PHP und wie sehen die aus?

Also ein typisches Problem bei Anfängern fängt schon beim Installieren und Konfigurieren von PHP an.
Weiterhin gibt es unter anderem bei Neulingen das Problem, dass sie nicht GET- und POST-Variablen abfragen können (register_globals auf no gesetzt).

Mir fallen sicher noch ein paar ein... *g*

Tu' Dir keinen Zwang an! ;-)

so short

Christoph Zurnieden

[Christoph]

Hallo

ich freue mich nun auf einen weiteren Beitrag von Sven Rautenberg zum Thema PHP und Anfängerfehler und PHP und Sicherheit!

Und das mein ich wirklich Ernst!

Gruß Christoph

[Sven Rautenberg]

Moin!

ich freue mich nun auf einen weiteren Beitrag von Sven Rautenberg zum Thema PHP und Anfängerfehler und PHP und Sicherheit!

Und das mein ich wirklich Ernst!

Meinen Beitrag recherchierst du bitte im Archiv.

Und das mein ich wirklich _nicht_ ernst. :)

Aber da steht mit Sicherheit viel drin, was nur mal gesammelt werden müßte.

Dummerweise fällt mir spontan gerade nicht sonderlich viel ein. Es ist immer leichter, aus Sicherheitssicht heraus zu argumentieren, etwas würde Lücken haben, als so rein theoretisch zu argumentieren.

Die typischen Probleme mit register_globals sind schon erwähnt worden. Es sei hierbei angemerkt, dass diese Option ein sehr zweischneidiges Schwert für PHP-Programmierer ist. Eigentlich sind die Verhältnisse nur geklärt, wenn register_globals=on zwingend ist! Dann ist man sich als Programmierer bewußt, dass man in unsicheren Gefilden agiert und ausnahmslos jede Variable, die man verwendet, vorher initialisieren muß. Geht man aber von der Stellung "off" aus, dann kann man viel leichter schlampen und bei dann doch aktiviertem register_globals die größten Probleme kriegen.

Deshalb wichtig: Auf dem Entwicklungsserver sollten wirklich _ALLE_ Fehlerlevel ausgegeben und beseitigt werden, auch die NOTICE, die bei nicht initialisierten Variablen ausgegeben wird. Standardmäßig wird NOTICE aber leider nicht ausgegeben, sondern unterdrückt. Und damit hätten wir schon den zweiten Punkt, den man bei Skripten prüfen sollte. Ein gutes Skript gibt keine NOTICE aus.

Punkt drei, den ich als Entwickler ärgerlich finde, weil er zu mehr Problemen führt, als er löst, sind magic_quotes_gpc! Auch diese Option kann ein oder ausgeschaltet sein. Ich bin mittlerweile der Meinung, sie müßte ganz dringend und zwingend auf AUS gesetzt sein. Typischerweise will man Daten eher selten in Datenbanken schreiben. Und selbst da ist das Escape-Zeichen nicht zwingend der Backslash - die Sybase-Quoting-Option ist ein gutes Beispiel dafür.

Addslashes() ist also für Datenbanken ziemlich nutzlos. Und es ist nervig, mit stripslashes() erst alle übergebenen Daten zurückzuwandeln.

Aber dadurch ergibt sich eine schöne Fehlerquelle. Wenn der Entwickler von magic_quotes_gpc=on ausgegangen ist, auf dem Server aber off eingestellt ist, oder auch umgekehrt, dann wird das zu mehr oder weniger Chaos führen.

Summa summarum: PHP hat zwei ziemlich unrühmliche Punkte, die das Leben des Programmierers nicht leicht machen. Es gilt hier besonders, auf die Servereinstellungen zu achten oder sie (z.B. mit .htaccess-Konfiguration) explizit vorzuschreiben. Entsprechend groß ist an diesen Punkten, die leider alle Skripte betreffen, die es gibt, das Fehlerpotential.

- Sven Rautenberg

[Christoph Zurnieden]

Hallo,

ich freue mich nun auf einen weiteren Beitrag von Sven Rautenberg zum Thema PHP und Anfängerfehler und PHP und Sicherheit!

Und das mein ich wirklich Ernst!

Meinen Beitrag recherchierst du bitte im Archiv.

Und das mein ich wirklich _nicht_ ernst. :)

Aber da steht mit Sicherheit viel drin, was nur mal gesammelt werden müßte.

Das kann ich nur bestätigen.
Ich poste hier ja wirklich nur, weil mir das einfach _zuviel_ war.

Dummerweise fällt mir spontan gerade nicht sonderlich viel ein.

Muß jetzt nicht unbedingt spontan sein ;-)

Es ist immer leichter, aus Sicherheitssicht heraus zu argumentieren, etwas würde Lücken haben, als so rein theoretisch zu argumentieren.

Tja, wär's leicht, hätte ich das auch alleine heben können ;-)

Die typischen Probleme mit register_globals sind schon erwähnt worden. Es sei hierbei angemerkt, dass diese Option ein sehr zweischneidiges Schwert für PHP-Programmierer ist. Eigentlich sind die Verhältnisse nur geklärt, wenn register_globals=on zwingend ist! Dann ist man sich als Programmierer bewußt, dass man in unsicheren Gefilden agiert und ausnahmslos jede Variable, die man verwendet, vorher initialisieren muß. Geht man aber von der Stellung "off" aus, dann kann man viel leichter schlampen und bei dann doch aktiviertem register_globals die größten Probleme kriegen.

Aha, danke, da haben wir doch schon mal ein Indiz. Wenn auch nicht speziell für PHP, denn Variablen sollte man eigentlich immer initialisieren.

Deshalb wichtig: Auf dem Entwicklungsserver sollten wirklich _ALLE_ Fehlerlevel ausgegeben und beseitigt werden, auch die NOTICE, die bei nicht initialisierten Variablen ausgegeben wird. Standardmäßig wird NOTICE aber leider nicht ausgegeben, sondern unterdrückt. Und damit hätten wir schon den zweiten Punkt, den man bei Skripten prüfen sollte. Ein gutes Skript gibt keine NOTICE aus.

Gibt es eigentlich bei PHP eine Compile-Time Option für so etwas wie
'gcc -Wall -Werror -ansi -pedantic'?

Summa summarum: PHP hat zwei ziemlich unrühmliche Punkte, die das Leben des Programmierers nicht leicht machen. Es gilt hier besonders, auf die Servereinstellungen zu achten oder sie (z.B. mit .htaccess-Konfiguration) explizit vorzuschreiben. Entsprechend groß ist an diesen Punkten, die leider alle Skripte betreffen, die es gibt, das Fehlerpotential.

"Der gute Programmierer setzt rein gar nix vorraus, noch nicht einmal die Deckung des Gehaltschecks!" ;-)

Gibt es wirklich nichts Spezielles? Heißt also: Archive runterladen und durchgreppen?

Na gut, aber den Versuch war es wert.

Aber auf jedene Fall: besten Dank für dei Antwort!

so short

Christoph Zurnieden

[Andreas Korthaus]

Hi!

Vielleicht helfen folgende Links:

-> http://www.dclp-faq.de/ch/ch-code.html
-> http://de3.php.net/manual/de/security.php
-> </archiv/2003/5/46801/>

Grüße
Andreas

[Christoph Zurnieden]

Hallo,

Vielleicht helfen folgende Links:

-> http://www.dclp-faq.de/ch/ch-code.html
-> http://de3.php.net/manual/de/security.php
-> </archiv/2003/5/46801/>

Nein, leider nicht.
Trotzdem danke!

so short

Christoph Zurnieden

[lulu]

Hallo Christoph

Worum es eigentlich geht: woran erkennt der PHP-mäßig unbedarfte Chef, das er sich eine rechte Graupe eingehandelt hat. Wenn ich das einmal so brutal formulieren darf ;-)

Verstehe ich das richtig, das Du Kriterien suchst um an Hand des
Source-Codes 'olle Graupen' von 'smarten Erbsen' zu unterscheiden?

Wenn der Chef Ahnung von Programmierung in einer Sprache X hat, sollte das kein Thema sein, denn Anfängercode sieht ja in vielen Sprachen ähnlich wuselig aus.

Wenn nicht sollte er sich wohl besser Rat von einer weiteren Person einholen.

Aber ein Anfänger kann sich ja auch per Copy und Paste professionell
ausehenden Code 'aneigenen', der Source Code kann also
ein Indiz für die (Un-)Fähigkeiten des PHPlers sein, mehr nicht.

Viele Grüße

lulu

[Christoph Zurnieden]

Hallo,

Worum es eigentlich geht: woran erkennt der PHP-mäßig unbedarfte Chef, das er sich eine rechte Graupe eingehandelt hat. Wenn ich das einmal so brutal formulieren darf ;-)

Verstehe ich das richtig, das Du Kriterien suchst um an Hand des
Source-Codes 'olle Graupen' von 'smarten Erbsen' zu unterscheiden?

Eigentlich ja, denn: woran sonst, wenn nicht an den Taten kann man den guten Programmierer vom Script-Kiddy unterscheiden?

Wenn der Chef Ahnung von Programmierung in einer Sprache X hat, sollte das kein Thema sein, denn Anfängercode sieht ja in vielen Sprachen ähnlich wuselig aus.

Nicht unbedingt, siehe auch: Perl ;-)

Wenn nicht sollte er sich wohl besser Rat von einer weiteren Person einholen.

So etwas kostet gemeinhin und das wird gerne vermieden.

Aber ein Anfänger kann sich ja auch per Copy und Paste professionell
ausehenden Code 'aneigenen', der Source Code kann also
ein Indiz für die (Un-)Fähigkeiten des PHPlers sein, mehr nicht.

_Das_ sieht man normalerweise sehr gut. Das mit dem C&P meine ich.
Denn den muß man ja immer einbauen ;-)

mit herzlichem Dank für die Antwort

Christoph Zurnieden

[Christian Seiler]

Hallo Christoph,

erst einmal schön, wieder mal etwas von Dir zu lesen.

Gibt es so etwas wie typische (Anfänger-)Fehler in PHP und wie sehen die aus?

Mal sehen, was mir da so einfällt:

register_globals, magic_quotes_gpc wurden ja schon erwähnt.

Dann hätten wir noch short_open_tag, also <? ?>, was nicht auf allen Systemen läuft. (Man sollte besser <?php bzw. <script language="php"> verwenden)

Beliebt scheint außerdem noch folgende Konstruktion zu sein:

if (strpos (/*...*/) == false) {
  /* ... */
}

Was natürlich bei Position 0 falsche Ergebnisse liefert. (Korrekt wäre ===) Dies gilt natürlich genauso für andere Dinge, wo ein == falsch ist.

Dann gibt es natürlich immer noch so schöne Dinge wie Fenster mit PHP öffnen oder ähnliche Dinge, wofür eigentlich JavaScript da ist. Allgemein mixen PHP-Anfänger gerne JavaScript und PHP und sind sich nicht klar, wie diese sauber getrennt werden.

Dann gibt es noch Location: index.php - was natürlich nicht standardkonform ist und von einigen Clients nicht verstanden wird. (insb. PHP selbst)

Wir hätten dann desweiteren noch so etwas hier:

if (eregi ($q, $suchtext)) { /* $q stehe hier für $_GET['q'] ;-( */
  echo 'gefunden!';
}

Was natürlich eine Fehlermeldung produzieren könnte, die evtl. Daten über den Server preisgibt; im besten Fall wundert sich ein Anfänger. Gerade ereg* sollte eigentlich vermieden werden - sowohl für einfache als auch für komplexe Ersetzungen, preg* ist besser.

Die Fehlerbehandlung ist auch ein wichtiger Punkt. Wenn keine Fehler behandelt werden, dann kann dies im Einzelfall durchaus zu ernsthaften Problemen führen, zum Beispiel Datenbankinkonsistenzen.

Zur Fehlerbehandlung wäre auch noch zu sagen, dass jeder, der Formulare nicht in Normalform schreibt, einen sehr guten Grund dafür haben sollte.

Außerdem ist es ein typischer Anfängerfehler, wenn jemand eine Browserkompabilitätsfrage unter dem Themenbereich PHP stellt. (Warum läuft meine PHP-Seite nicht unter Browser XYZ? Mein PHP-Quelltext sieht so aus: [10KB gesnippt])

Vor allem interessieren mich sicherheitstechnisch relevante Fehlleistungen, weniger der typische Anfänger, der nicht in die FAQ geschaut hat.

Aus eigener Erfahrung hier im Forum: Wer in die FAQ geschaut hat, der wird mit ziemlicher Sicherheit *keinen* typischen Anfängerfehler begehen.

woran erkennt der PHP-mäßig unbedarfte Chef, das er sich eine rechte Graupe eingehandelt hat.

Der Chef soll dem Mitarbeiter auferelgen, zur Demonstration ein Gästebuch zu schreiben. Er muss natürlich kontrollieren, dass dieser sich keiners herunterlädt. Wenn er es dann mit einfachen HTML-Codes "abschießen" kann, dann weiß er, wo er dran ist. Was besseres fällt mir dazu leider nicht ein.

Viele Grüße,
Christian

[Christoph Zurnieden]

Hi Christian,

erst einmal schön, wieder mal etwas von Dir zu lesen.

Naja, viel Streß in letzter Zeit.

Gibt es so etwas wie typische (Anfänger-)Fehler in PHP und wie sehen die aus?

Mal sehen, was mir da so einfällt:

Dann gibt es noch Location: index.php - was natürlich nicht standardkonform ist und von einigen Clients nicht verstanden wird. (insb. PHP selbst)

Das HTTP Location?

Die Fehlerbehandlung ist auch ein wichtiger Punkt. Wenn keine Fehler behandelt werden, dann kann dies im Einzelfall durchaus zu ernsthaften Problemen führen, zum Beispiel Datenbankinkonsistenzen.

Nunja, fehlende Fehlerbehandlung ist nicht unbedingt Anfängertypisch, leider ;-\ Aber das führt mich zu einer Nachfrage: ist die Datenbankanbindung von PHP so schlecht, das sie Inkonsistenzen zuläßt?

Zur Fehlerbehandlung wäre auch noch zu sagen, dass jeder, der Formulare nicht in Normalform schreibt, einen sehr guten Grund dafür haben sollte.

Gibt es denn einen?

Außerdem ist es ein typischer Anfängerfehler, wenn jemand eine Browserkompabilitätsfrage unter dem Themenbereich PHP stellt. (Warum läuft meine PHP-Seite nicht unter Browser XYZ? Mein PHP-Quelltext sieht so aus: [10KB gesnippt])

Aha, das ist doch schonmal etwas, das mir im Traum nicht eingefallen wäre ;-)

Vor allem interessieren mich sicherheitstechnisch relevante Fehlleistungen, weniger der typische Anfänger, der nicht in die FAQ geschaut hat.

Aus eigener Erfahrung hier im Forum: Wer in die FAQ geschaut hat, der wird mit ziemlicher Sicherheit *keinen* typischen Anfängerfehler begehen.

Oh, doch schon so komplett?

woran erkennt der PHP-mäßig unbedarfte Chef, das er sich eine rechte Graupe eingehandelt hat.

Der Chef soll dem Mitarbeiter auferelgen, zur Demonstration ein Gästebuch zu schreiben. Er muss natürlich kontrollieren, dass dieser sich keiners herunterlädt.

Naja, also eigentlich spräche es ja für den Mitarbeiter, wenn er sich eines herunterläde. Spart schließlich Entwicklungskosten! ;-)

Wenn er es dann mit einfachen HTML-Codes "abschießen" kann, dann weiß er, wo er dran ist. Was besseres fällt mir dazu leider nicht ein.

Dafür bräuchte der Chef aber doch schon einige Kenntnisse.
Oder einen Link. ;-)

Aber ich muß nun also abschließend feststellen, das es leider keine eindeutigen Hinweise für einen unbedarften Chef gibt. Das ist nicht weiter schlimm, denn das stellt im Grunde genommen auch nur eine Marktlücke da, aber halt nicht sehr schön.

Aber ich muß mich natürlich auch bei Dir bedanken!

so short

Christoph Zurnieden

[Sven Rautenberg]

Moin!

Dann gibt es noch Location: index.php - was natürlich nicht standardkonform ist und von einigen Clients nicht verstanden wird. (insb. PHP selbst)

Das HTTP Location?

Genau. Der Standard fordert die Angabe einer absoluten URL inklusive "http://". Relative URLs funktioniern nur manchmal.

Die Fehlerbehandlung ist auch ein wichtiger Punkt. Wenn keine Fehler behandelt werden, dann kann dies im Einzelfall durchaus zu ernsthaften Problemen führen, zum Beispiel Datenbankinkonsistenzen.

Nunja, fehlende Fehlerbehandlung ist nicht unbedingt Anfängertypisch, leider ;-\ Aber das führt mich zu einer Nachfrage: ist die Datenbankanbindung von PHP so schlecht, das sie Inkonsistenzen zuläßt?

Nein, die DB-Anbindung ist nicht so schlecht. Das Problem ist, dass Mißerfolge beim Schreiben in die DB irgendwie Beachtung finden müssen - insbesondere, wenn man die Konsistenz der DB selber herstellen muß, wie z.B. bei MySQL.

Naja, also eigentlich spräche es ja für den Mitarbeiter, wenn er sich eines herunterläde. Spart schließlich Entwicklungskosten! ;-)

Dann sei der Mitarbeiter daran gemessen, _welches_ Gästebuch er sich runterlädt. Blind irgendeins runterladen ist nämlich genauso böse. :)

Aber ich muß nun also abschließend feststellen, das es leider keine eindeutigen Hinweise für einen unbedarften Chef gibt. Das ist nicht weiter schlimm, denn das stellt im Grunde genommen auch nur eine Marktlücke da, aber halt nicht sehr schön.

Was hattest du erwartet? Um zu prüfen, ob das Arbeitsergebnis eines eingekauften Experten wirklich professionellen Anspruchen genügt, bedarf es eines mindestens gleichwertigen Experten, der das Arbeitsergebnis kontrolliert. Das schließt die Berufsgruppe "Chef" eigentlich schon prinzipiell aus, erst recht die Unbedarften. :)

- Sven Rautenberg

[Christoph Zurnieden]

Hi,

Dann gibt es noch Location: index.php - was natürlich nicht standardkonform ist und von einigen Clients nicht verstanden wird. (insb. PHP selbst)

Das HTTP Location?

Genau. Der Standard fordert die Angabe einer absoluten URL inklusive "http://". Relative URLs funktioniern nur manchmal.

Ja, da ich hätte wohl ein Smiley hinter malen müssen, aber es gibt halt keines, das meiner Verwunderung hätte ausreichend Ausdruck geben können. Es gibt ja schon nicht sehr viele und große Standards im Webgeschäft, eigentlich nur eine Handvoll und die auch noch kurz und knapp ("...und unverständlich", wie manch einer hier hinzufügen möchte, mich eingeschlossen ;-), die sollte man doch schon kennen, oder?

Aber das führt mich zu einer Nachfrage: ist die Datenbankanbindung von PHP so schlecht, das sie Inkonsistenzen zuläßt?

Nein, die DB-Anbindung ist nicht so schlecht. Das Problem ist, dass Mißerfolge beim Schreiben in die DB irgendwie Beachtung finden müssen - insbesondere, wenn man die Konsistenz der DB selber herstellen muß, wie z.B. bei MySQL.

Ah! Ich dachte da an Datenbanken, nicht MySQL (Standardversion), das ist schon etwas anderes!
Datenbankoperationen müssen atomar sein, entweder geht es ganz oder gar nicht. Alles andere bereitet nur Magengeschwüre.
Auch ist die Spielerei mit Datenbanken nun wirklich ein Areal für Profis, da sollte ein Skriptkiddy mit PHP nix herumpfuschen dürfen, die Benutzung muß seiteneffektfrei sein.

Naja, also eigentlich spräche es ja für den Mitarbeiter, wenn er sich eines herunterläde. Spart schließlich Entwicklungskosten! ;-)

Dann sei der Mitarbeiter daran gemessen, _welches_ Gästebuch er sich runterlädt. Blind irgendeins runterladen ist nämlich genauso böse. :)

Ja, doch, das ist ein guter Maßstab ;-)

Aber ich muß nun also abschließend feststellen, das es leider keine eindeutigen Hinweise für einen unbedarften Chef gibt. Das ist nicht weiter schlimm, denn das stellt im Grunde genommen auch nur eine Marktlücke da, aber halt nicht sehr schön.

Was hattest du erwartet?

Nunja, die Hoffnung stirbt zuletzt, oder? ;-)

Um zu prüfen, ob das Arbeitsergebnis eines eingekauften Experten wirklich professionellen Anspruchen genügt, bedarf es eines mindestens gleichwertigen Experten, der das Arbeitsergebnis kontrolliert.

Tja, wie heißt es doch so schön bei Juvenal (II,6 Z. 347 f.)?

Pone seram; cohibe: sed quis custodiet ipsos
Custodes?  cauta est, et ab illis incipit uxor.

Das schließt die Berufsgruppe "Chef" eigentlich schon prinzipiell aus, erst recht die Unbedarften. :)

Einen 10-Punkte Leitfaden hatte ich nun wirklich nicht erwartet, es ist aber trotzdem sehr viel zusammengekommen! Damit kann man doch schon mal etwas anfangen.

so short

Christoph Zurnieden

[Christian Seiler]

Hallo Christoph,

Ah! Ich dachte da an Datenbanken, nicht MySQL (Standardversion), das ist schon etwas anderes!

MySQL ist IMHO durchaus eine Datenbank. Ab Version 4.nochwas unterstützt sie ja auch Transaktionen. Allerdings nutzen Dir auch Transaktionen *gar nichts*, wenn jemand folgendes macht:

1. INSERT INTO a ... (produziert Fehler, wird jedoch nicht kontrolliert)
2. INSERT INTO b ... (schreibt korrekt)
3. COMMIT

Und genau darum ging es mir.

Auch ist die Spielerei mit Datenbanken nun wirklich ein Areal für Profis, da sollte ein Skriptkiddy mit PHP nix herumpfuschen dürfen, die Benutzung muß seiteneffektfrei sein.

Naja, jeder hat irgendwie mal klein Angefangen, daher kann ich den Satz so direkt nicht unterschreiben.

Viele Grüße,
Christian

[Christoph Zurnieden]

Hi Christian,

Ah! Ich dachte da an Datenbanken, nicht MySQL (Standardversion), das ist schon etwas anderes!

MySQL ist IMHO durchaus eine Datenbank.

Fehlte da mal wieder das Grinsemännchen bei mir? Nein! >;->

Ab Version 4.nochwas unterstützt sie ja auch Transaktionen. Allerdings nutzen Dir auch Transaktionen *gar nichts*, wenn jemand folgendes macht:

1. INSERT INTO a ... (produziert Fehler, wird jedoch nicht kontrolliert)
2. INSERT INTO b ... (schreibt korrekt)
3. COMMIT

Und genau darum ging es mir.

Ja, mir auch! Eine gute Datenbankanbindung muß das da oben alles zusammen atomar behandeln. Fällt eines aus, ist alles hinfällig. kann sie das nicht, brauch ich keine API, dann kann ich das genauso gut von Hand machen. Aber die PHP-Datenbankanbindung ist ja auch nichts anderes als ein wenig "glue".
Das führte mich denn ja auch zu dem folgendem Satz.

Auch ist die Spielerei mit Datenbanken nun wirklich ein Areal für Profis, da sollte ein Skriptkiddy mit PHP nix herumpfuschen dürfen, die Benutzung muß seiteneffektfrei sein.

Naja, jeder hat irgendwie mal klein Angefangen, daher kann ich den Satz so direkt nicht unterschreiben.

Nunja, man sollte dann aber nicht unbedingt auf einem Produktionsserver seine Erfahrungen sammeln ;-)

Datenbanken sind nun einmal "Hohe Kunst(TM)". Ich selber erhöhe die Anzahl der zulässigen Prozesse auf dem laufendem Produktionsserver direkt in /dev/kmem. Ohne mit der Wimper zu zucken. Aber eine große und verschachtelte Datenbank bauen? Da habe ich dann doch lieber einen Spezialisten an meiner Seite ;-)

so short

Christoph Zurnieden