[php] PHP, mySQL - OpenSource

[Markus Wolff]

Am Wed, 6 Feb 2002 13:27:56 +0100 schrieb "Beck, Mike"
<mike.beck_(at)_ibmiller.de>:

> > Erst Transaktionssupport, aber keine referentielle Integrität -
> > was nützt es, wenn ich ganz toll dafür sorgen kann, daß alle Daten
> > sauber zusammenhängend in der Datenbank landen, wenn ich anschließend
> > nicht garantieren kann, daß deren Zusammenhang auch gewahrt bleibt?
>
> ganz einfach - referentielle Integrität brauch man nicht wirklich - das
> lässt sich durch ein bischen mitdenken beim Programmieren problemlos
> ersetzen, während Transaktionen wirklich wichtig waren.

1. Programmierer sind faul
2. Programmierer machen Fehler

Speziell letzteres ist bei großen Projekten (und nur von solchen wird
hier geredet, denn nur hierfür sind _alle_ diese Features wichtig) ein
Problem: Wenn ein Programmierer z.B. beim Löschen oder Ändern von
Datensätzen irgendwo in einer Tabelle etwas vergißt, so bekommt er
keinen Fehler ausgeworfen. D.h. es entstehen Inkonsistenzen in der
Datenbank, die im günstigsten Fall bei größerer Anzahl von Datensätzen
Performance und Speicherplatz schlucken, im ungünstigsten Fall
Berechnungsfehler verursachen, die evtl. erst viel später entdeckt
werden, wenn schon viel Schaden verursacht wurde.

Mit referentieller Integrität und entsprechend gleich in der Datenbank
angelegten Constraints kann Dir sowas nicht passieren.

> *ROFL*
> erstens lies Dir mal die Supportangebote durch, die fangen durchaus bei
> Beträgen und dementsprechend auch Reaktionszeiten die für kleine Firmen
> interessant sind an.

Das habe ich doch gar nicht bestritten. Mein Unverständnis bezieht sich
darauf, daß MySQL AB erst entsprechende Supportverträge _auch_ für
Großfirmen konzipiert, anstatt erstmal für Großfirmen sinnvolle Features
einzubauen. Daß es für kleinere Firmen keinen Support gibt, habe ich nie
behauptet.

> zweitens - für Großfirmen uninteressant? das ist mit neu, ein paar von den
> Kunden von MySQL AB hätte ich durchaus für groß gehalten, aber
> wahrscheinlich ist das nur eine Sache der Perspektive. Wenn man natürlich
> meint einen Server nicht brauchen zu können weil er zwar um ein vielfaches
> schneller und günstiger ist, aber keine referentielle Integrität bietet,
> dann sollte man natürlich unbedingt Oracle nehmen ;-)

Oder PostgreSQL, was auch keinen Pfennig kostet, da GPL - und alle
relevanten geschäftskritischen Funktionen beinhaltet. Und auch im
kommerziellen Umfeld gibt es genügend preisgünstigere Alternativen zu
Oracle.

Und was die Kunden von MySQL angeht, nungut, vielleicht hätte ich es
noch ausführlicher formulieren sollen: Es mag ja sein, daß auch größere
Firmen MySQL einsetzen, aber nie im Leben für geschäftskritische
Anwendungen.

Wenn es um Webanwendungen geht, die hauptsächlich Daten präsentieren,
aber nicht verarbeiten müssen (z.B. die Liveserverkomponenten von
Content Management Systemen): Ja, MySQL, sofort! Ich benutze MySQL
selber sehr oft und zwar genau für solche Dinge (dennoch wünsche ich mir
auch für solche Anwendungen dringend Subselects...).

Will ich ein CRM-, Warenwirtschafts-, Depotverwaltungs- oder ähnlich
kritisches System umsetzen, ist MySQL ein absolutes no-no.

Gruß,
 Markus

--
*21st Media*    | Consulting, Konzeption, Produktion für die Bereiche:
Markus Wolff    | Internet, Intranet, eCommerce, Content Management,
Hamburg,Germany | Softwareentwicklung, 3D-Animation, Videostreaming
http://21st.de  | Tel. [+49](0)40/6887949-0, Fax: [+49](0)40/6887949-1