linux-l: Frage zu MySQL

[Dr. Bernd Freistedt]

Hey Marc,

Du haast ja sooo recht, jedenphalls teilweise :-)
ABER(!)

---Marc Ende (linux-l at mlists.in-berlin.de) wrote on Thu, 15 Nov 2001 20:12:56 +0100 (CET)

> Nun, MySQL entwickelt sich ja auch weiter. Es fehlen halt noch einige 
> Dinge, 

subselects, rules, eben alles was eine DB richtig geil macht, so
z.B. autotracking - das fehlt halt und ich sehe da auch noch nix.

> die man von einer fullfeatured Datenbank erwartet. Man sollte halt
> schauen, was für ein Projekt man vor hat (und welches Budget) und sich 
> dann nach einer entsprechenden DB umschauen (es muß nicht immer DB2, 
> Oracle und Konsorten sein).

Ooooch, sooooo'n Wunderwerk ist Oracle nun auch nicht. Ist halt
eine Datenbank aus einer verdammt clever gemanageten Bude.

> Warum es dann nicht postgresql ist? Nun, ich weiß nicht, vielleicht wurde 
> postgresql einfach nicht genug ins Rampenlicht gehoben oder war einfach 
> zur falschen Zeit am falschen Ort... :)

Ob Berkeley der falsche Ort ist, ....? - *gruebel*
Gut, sie war bis vor noch allzu langer Zeit ein wenig "eckiger" zu
handhaben und ist eben nicht so - sagen wir's mal vorsichtig -
trivial wie MySQL.
Zu PostgreSQL gab's frueher nicht so gute Literatur und null
Support - das war freilich ein Manko.

> Ich denke einfach MySQL hat gerade in 
> der Zeit als php aufkam auch entsprechend zulauf gefunden (es gab jede 
> menge Artikel über LAMP und über LAPP hab ich nicht viel gelesen).

Genau _das_ kam zusammen. Aber das Ergebnis von LAMP ist bisher eine
"WebClient-WebServer-Anwendung light" (ueber die zend engine
wurde an dieser Stelle schon ausreichend abfaellig diskutiert),
also nix genaues fuer Security-Paranoiker ;-)
Fuer 'ne Rolle Drops aus'm Internet-Shop zu kaufen reicht's.

> Leichtgewicht ist gut. Es gab Vergleiche zwischen MySQL und Oracle und da 
> hat MySQL im typischen Anwendungsgebiet fast genausogut abgeschnitten.

Was ist das "typische Anwendungsgebiet" einer Datenbank?
Doch nicht etwa (Schlagwort) "Warehousing und ieh-Kommoers"....?

> Wie oben schon erwähnt, es kommt auf das Projekt drauf an.

richtig.

> ERP unter PostgreSQL oder MySQL ist sicher nichts, was man so
> unbedingt möchte... 

Wie?! unter PostgreSQL nicht? Das ist doch gerade das Mittel
der Wahl, wenn Du fuer anspruchsvolleres Open Source verwenden
willst (leider wollen das so wenige und nehmen gleich aus
Imagegruenden Oracle, da brauchste nix zu validieren, das
glauben Dir auf Anhieb alle :-( ).

> Nun php ist in seiner Form besser zu gebrauchen als die in ihrem Typ 
> ähnlichen Sprachen.

Hoffentlich weiss der, der PHP schreibt, was er tut.

>> Ich verwende Python (cgi) ;-)
> 
> It's up to you... Wenns der Provider unterstützt... ;)

Dafuer braucht's doch keinen Provider :-))

Ausserdem kannst Du fuer billiges Geld (ca. 250,-DM/mon) bei
Puretec (1&1) die eigene Kiste nach Gusto hosten lassen. Da ist
alles dabei, bloss nicht die Sorgen des Backup, das machen die.

>> Speed. Dass sie mit der Zeit etwas "Luft aufnimmt", laesst sich
>> durch gelegentliches vakuum (cron) schnell beheben.
> 
> Aber warum tut sie das nicht von alleine? 

Hm, ich denke, it's not a bug, it's a feature.
delete from... heisst eben nicht gleich "loeschen", obwohl's
eigentlich weg ist. Ein wichtiger Grund noch: Performance.

> Definier doch mal "richtiges" SQL.
> 
> Das sagt die Doku von MySQL zu Standards:
> ---
> Entry level SQL92. ODBC levels 0-2.

Ja, ja, 89/92er SQL-Standard.... aber das ist das
_Mindest_-mass, auf das zu erfuellen sich alle geeinigt haben.
Richtig spannend wird's dann mit den "Schleifchen" :-)

Allerdings darf nicht verschwiegen werden, dass man oraclend
selbst eine UltraSparc mit einer 200-Zeilen-Query
einschliesslich solcher Kinkerlitzchen wie outer joins schoen
zum Kotzen bringen kann.
Datenbanken haben halt nix mit Hexerei zu tun.

Gruessli
Bernd