linux-l: datenbanken

[Steffen Dettmer]

* Dr. Bernd Freistedt wrote on Fri, Aug 03, 2001 at 18:42 +0200:
> ---Steffen Dettmer (linux-l at mlists.in-berlin.de) wrote on Fri, 3 Aug 2001 16:22:30 +0200
> > * Guntram Trebs wrote on Thu, Aug 02, 2001 at 22:27 +0200:
> 
> > postgres unterstützt ihn auch nicht vollständig, aber das
> > wichtigeste ist dabei, vor allem verschiedene Berechtigungen und
> > Transaktionen.
> 
> Welches ausgewachsnene RDBS folgt ueberbaupt dem 92er oder 95
> Standard? - 

"Folgen" im Sinne der groben Richtung schon :) 

> Noch eigentlich keins. Jede hat ihre eigenen Schleifchen und
> Schmankerln darangehaengt.

So natürlich auch Postgres :) Damit kann man dann auch mit
PostgreSQL schön abhängige Programme bauen. Na ja, nicht mal bei
der Wahl der Quotierungszeichen ist man sich einig, und
Quotierungszeichen lassen sich auch schlecht über Variablen
implementieren (liest sich schlecht) und überhaupt aber egal :)

> Wenn wir davon ausgehen koennen, dass postgres (mit seiner
> inzwischen langen Entwicklungszeit) vielfach als Vorlage fuer
> die grossen kommerziellen diente, duerfte sie noch am ehesten am
> Standard liegen. Der Augenschein bestaetigt diesen Schluss.

Aber es ist schon erstaunlich, daß Fremdschlüssel erst mit
Version 7.0 (oder so etwa) implementiert wurden...

> > Was mich jedesmal wundert.
> 
> Mit vollem Risiko, dafuer Dresche zu beziehen: Das ist auch
> meine Meinung. mysql eignet sich fuer fast & dirty hervorragend,
> doch wenn's um wichtigeres geht, wuerde ich immer zu postgres
> greifen. Dazu kommen (uebrigens SQL-Standard-konforme) Features,
> die mysql nicht aufweist (subselects, outer joins, rollback).

rollback können die wohl inzwischen auch, oder? Verstehe nur
nicht, wie Q&D mit mySQL besser geht, als mit PG?

> > Für Postgres gibt's pgaccess. 
> 
> Das ist sogar deutlich komfortabler, als die Pendants
> Kmysqladmin und Mysqlgui fuer mysql, auch wenn's bei deutschen
> Umlauten leider nicht mitspielt.

Ja, stimmt. Na ja, ein paar Features fehlen mir da auch noch.
z.b. ne SQL Shell (falls man mal einen Sequenzwert korrigieren
muß oder so) wäre praktisch. Na, jedenfalls fetzt pgaccess, und
ist auch ziemlich stabil, ist ja wichtig.

Postgres hat aber schon ein paar Macken, denke mal, das ist bei
mySQL nicht besser. z.B. werden views als Tabellen gedumpt,
schlecht fürs Backup. Und dann gab's noch ne Kombination, ich
glaube cluster index auf Tabellen, die auch von einem View
verwendet werden oder so, was den postmaster crasht. Stimmt,
wollte das mal provozieren und einen Bugreport schreiben. Man
kommt immer zu nix.

> > :) Ja, wenn man PHP mag, wird Access lieben. Aber beides nix für
> > mich. Inzwischen kriege ich immer schwitzige Hände, einen
> > wahnsinnigen Blick und Ohrensausen wenn ich PHP (nein, schon
> > wieder) lese/höre... Und ganz besonders mod_php (fröstel). 
> 
> Ummm, was hat den PHP mit Access zu tun?

Na, sind beides Eierlegende Wollmichsäue, die von sich behaupten,
einfach programmierbar zu sein, was Leute, die nicht
programmieren können, dazu verleitet, es dennoch zu tun usw.
Beides versucht Fehler (die keine Beschreibung liefern) möglichst
automatisch zu korrieren - na ja, subjektiver Eindruck.

> >> Für Webseiten würde ich Dir diese Kombination empfehlen.
> 
> Trotzdem regen Deine Argumente zum Nachdenken kann.
> Man kann eine browsergaengige Datenbankanwendung schreiben in 
> z. B.:
> - php
> - perl
> - auch bash ;-)

"kann" sicherlich. Aber man muß die Vorteile/Nachteile abwägen.
Perl kennt z.B. den Taint-Modus. Ein user kann sich eigene Module
bauen und CPAN module verwenden (ohne "root" nerven zu müssen).
Dann geht's über SuExec, was eigentlich ne Bedingung für jeden
Admin sein müßte (aber die Kunden _verlangen_ eben PHP...). Bash
ist natürlich grenzenlos umständlich... Ein Vorteil von PHP ist
dieses Session-Zeugs. Läuft irgentwie über ein /tmp/file. Das ist
in meinen Augen schon frech. Dann läuft der Mist mit
Serverrechten, auch frech. Na ja, eben nix für mich.

> Ich denke immer, cgi-bin's sind hinsichtlich Sicherheit
> problematischer....

Was sind "cgi-bin's"? CGI als binaries? Wenn man da Ada nimmt,
und den Kram ordentlich macht, ist da bestimmt nix problematisch
:)

> Aber nun Du:
> 
> > Warum? Ich finde es unsicher, unsauber, buggy, gefährlich und
> > instabil:
> > - mod_php startet jedes Script im gleichen Prozeß/Environment
> 
> Das ist eigentlich der Vorteil, indem eine Menge an Variablen
> nicht jedes Mal einzeln betuttert werden muss.

Eben. Man tauscht etwas Performance gegen Stabilität und
Sicherheit. Eben nix für mich. Lieber 0.3s langsamer, dafür
sicher, stabil usw.

> > - mod_php funktioniert nicht mit suexec
> 
> Braucht man das? - Man kann sich auch anders helfen.

Oh, ja, klär mich mal bitte auf, wie das möglich sein soll! Ich
denke eben, es geht nicht anders.

 [...] 
> Das waren nun viele Gruende, die dagegen sprechen. Man muss sie
> akzeptieren.

Oder gegen argumentieren.

> > Ich empfehle daher apache+suexec+perl5+mods-Deiner-wahl.
>  
> Hm, und dann perl in den Code stecken. Ist das nicht ebenso
> "unsicher"?

Kann schon. Aber mit Perl hat man immerhin die Möglichkeit,
stabile Dinge zu machen. Nicht mit "experimenteller
Objektorientierung" wie in PHP, wo man bestimmte Sachen nicht
aufrufen darf, weil PHP (bzw. zend) dann abstürtzt, sonder was
funktioniert und stabil ist usw. Außerdem ist der Taint-Mode
wirklich genial und konsequent implementiert. Die
"Sicherheitsmechnismen" von PHP hingegen sind unübersichtlich, im
Prinzip ne Sammlung von Verboten gegen Einzelfälle, die zum
Kompott ständig erweitert werden müssen, weil ständig jemand
einen neuen Fall findet. Taint hingegen ist einfach, sauber und
vollständig. Taint arbeitet "ganz unten", PHP versucht, "ganz
oben ein paar Dinge abzufangen, die ganz untern gefährlich sein
könnten". Kann ja nicht gehen.

> Letztenendes kann man seine Anwendungen mit unseren guten alten
> GNU-Tools als cgi bauen mit 
>     psql -A db user -c "select pi,pa,po from ... usw" |\
>     awk -F"|" '{
>        print "irgendwelche_HTML-Tags" $2 " andere_HTML_Tags"
>     }'

Na, dann mach mal mit Bash eine Input-Validierung. Dann mußt du
auch noch selbst aufpassen, ob alle Variablen suaber sind -
übersiehst Du eine, hast Du verloren. Schon alleine URL-excaping
wird mit bash schwierig. Ach so, awk aufrufen ist
Performancebremse ohne Ende, merkt man, wenn man diese Anweisung
in einer Schleife braucht (übrigens kann bash auch inzwischen
extrem viel, printf und sowas). Sicher oder wiederverwendbar
wirds auch kaum usw.

> Es geht vieles.
> Aber wenn ich die Prozessorlasten vergleiche....

Perl ist schnell. Perl ist eigentlich mehr ein Compiler.
Funktioniert wohl so bißchen wie Java mit just-in-time
compilation. In Perl kann man sogar system calls machen, z.B.
wenn man ein select braucht oder weiß ich was. Bei Perl merkt
man, daß der Kram 20 Jahre alt ist und extrem durchdacht ist. Bei
PHP? Na, man nahm da so ne zend_engine, von der vorher vermutlich
nie jemand was gehört hat (und die auch nicht sehr stabil ist),
und bastelt alle Funktionen rum, die einem einfallen. Die gibt's
nicht etwa als Zusätze, die erst nach vielen Tests in die
Distribution eingehen, sondern als eingebaute, hard
eincompilierte, höchst systemabhängige Sch____. Ach so, und zum
Kompott meint man noch das Rad neu erfinden zu müssen, so daß PHP
immer wieder Bugs hat, die andere schon längst gefixt haben.
Dieses schlecht getestete Konglomerat ist dann eben nix für mich.

Aber in einem Punkt magst Du Recht haben: Performance. Die
zend_enginge ist bestimmt sehr schnell, schließlich verwendet man
keine Rechenzeit auf irgentwelche Prüfungen. Schau die einfach
mal den Code von zend_execute an :) Das ist so komplex, da kann
man ja gar nicht mehr durchsehen, und wenn bei -DEBUG lediglich
die Fehlermeldung bei einem fehlgeschlagenen realloc hinzukommen,
jedoch keinerlei Prüfungen wie asserts usw., dann kann man da ja
nix sicher machen, weil man beim debuggen die Fehler nicht mal
findet. Das spiegelt sich auch in der Bugdatenbank wieder: "...
nicht reproduzierbar, keine Fehlerbeschreibung, closed" liest man
da häufig. Die Ursachen dafür sind für mich klar: ändert ein
anderes Script durch einen zend Bug irgentwo was, stürtzt das
nächste Script ab. Danach geht es plötzlich. Weil Apache die
Prozeße ständig neustartet, wenn die segfaulten, fällt dem User
das nicht weiter auf. Und weil die PHP Programmierer keine
solchen sind, ändern die dann ihr "return (undef);" (was zum
Absturz führte) gegen "return (0);" (was dann zufällig nicht mehr
zum Absturz führte, wie bei races so üblich), und denken, es wäre
ihr Fehler (dabei darf man mit return sonstwas nie nie ein
Segfault in einer Scriptsprach hinkriegen), und es gibt nicht mal
einen Bugreport. Na, und wenn, nützts auch keinem, weil es eben
nicht reproduzierbar ist und keine Fehlermeldungen kommen
("assertion failed in zend_execute:123; p == 0xabcd, *p == NULL,
**p not available while processing return value in line 123 of
hello.php [attempt to dereference NULL pointer]" oder sowas
gibt's da eben nicht).

So, muß einkaufen. :)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.