linux-l: datenbanken

[Dr. Bernd Freistedt]

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

>> mysql unterstützt nicht den vollen SQL-Standard, unter anderem aus
>> Performance-Gründen. 
> 
> 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? - Noch eigentlich keins. Jede hat ihre eigenen
Schleifchen und Schmankerln darangehaengt.

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.

>> Vorteil von mysql ist, dass es bei Internet-Providern weit
>> verbreitet ist.
> 
> 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).
 
> 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, 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?

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

Meinetwegen auch andere.
Ich denke immer, cgi-bin's sind hinsichtlich Sicherheit
problematischer....
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.

> - mod_php funktioniert nicht mit suexec

Braucht man das? - Man kann sich auch anders helfen.

> - mod_php hat viele sicherheitsrelevante bugs
> - mod_php implementiert ein "Sicherheitssystem", was falsche
>   Sicherheit suggeriert
> - mod_php ist dynamisch fast gegen /usr/lib/* gelinkt und damit
>   höchst unportabel (man muß immer alle libs dahaben, um es
>   kompilieren zu können, und dann kann das Verhalten abweichen
>   usw.)
> - Jedes (!) php Script hat Zugriff auf den Lib Kram und ist damit
>   durch deren bugs potentiell gefährdet 
> - php muß die neusten Versionen der libs haben, auch wenn die
>   nicht lange in der Praxis liefen
> - die Bugdatenbank von PHP treibt mir Tränen in die Augen
> - die zend_engine ist nicht zuverlässig (ach so, muß da noch
>   meinen patch/bugreport machen :)) und der code sieht auch nicht
>   gut aus, nichtmal asserts() usw, kaum Fehlerprüfung, selbst bei
>   -DDEBUG
> - das configure läuft auf ner SuSE nicht ohne patchen durch (und
>   anhand der Marktanteile ist SuSE nicht exotisch)
> - ich hatte bisher bei *jedem* PHP update Probleme, weil viele
>   nicht mehr richtig funktionierte und nix reproduzierbar ist

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

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

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"
    }'

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

Gruessli
Bernd