phpbar.de logo

Mailinglisten-Archive

[php] MySQL <-> PostgreSQL

[php] MySQL <-> PostgreSQL

Marc Ende me at e-beyond.de
Mit Nov 24 15:43:50 CET 2004


Hi Sebastian,

> Mir fehlt etwas die Fantasie zu verstehen wo für die Datenkonsistenz
> Trigger nicht ausreichen in normalisierten DB?

Ich denke das hängt von der Struktur ab. Normalisiert sollte sie schon
sein, allerdings gibts selbst in normalisierten Datenbanken
Konstrukte, die nicht ganz einfach sind. Wenn man bislang nur mit
Datenbanken ohne z.B. Foreign Keys gearbeitet hat, ist man sicherlich
noch nicht in diese Probleme gerannt, aber wenn es dann kniffliger
wird, sollte man dann schon trigger bemühen.

Übrigens, weil du unten Views erwähntest. In Views kann man lediglich
lesen, das Schreiben wird (unter Postgres) über Trigger erledigt, wenn
es sich um Views über mehrere Tables handelt.

> eine DB soll: einfügen, anzeigen, löschen, oder?

Was auf Webanwendungen auch zutrifft, da macht man auch nichts anderes
damit. U.a. könnte man diese Probleme auch prima mit Excel lösen (Die
Performance geht dabei zwar etwas in die Knie, aber gehen sollte es).
:)

Nicht umsonst gibts ja sqlite.

> Den Rest (Auswertung, Analyse, Presentation, ...) sollte eigentlich
> alles die Anwendung machen.

Nö, stimmt nicht. Es gibt schon gute Gründe, warum man das nicht der
Applikation überläßt. Warum sollte ich bei Millarden von Datensätzen,
diese auf eine Applikation schaufeln, sie analysieren und dann
zurückschreiben. Mach das mal in einem Webseitenaufruf, da dürfte man
das dann deutlich erkennen.

> Duplizierung von Code wird durch die Verwendung von Klassen
> entgegengewirkt, wird ein Frontend in einer anderen Sprache
> geschrieben
> muss man wohl in den sauren Apfel beißen.

Stimmt, der Duplizierung von Code kann man so entgegenwirken, aber
warum sollte man Dinge nicht an der Stelle machen, die dafür ggf.
sogar entwickelt worden ist. (Zum Beispiel Postgres mit "r")

> Ein was sinnvolles in diesem Zusammenhang wären so gennante 'Views',
> die
> sollten wirklich in der DB gespeichert werden können,

Werden sie ja auch.

> z. B. statt 'SELECT ... ein superlanges select mit 20 joins ...'
>
> einfach: 'SELECT * meinview WHERE '

Views halte ich aus Performancegründen für Webseiten für eine Bremse.
In der Regel gibts du, wie oben geschrieben dein Select ab. Dieses
führt dann das Select aus, mit dem die View die Daten zusammenstellt
und
zurückgibt. D.h. aus Bequemlichkeit ein SELECT zu viel. Man kann zwar
mittels EXPLAIN einiges optimieren, aber wenn man wert auf Performance
legt sicherlich nicht optimal.

> aber eigentlich auch alles egal, es ändert ja nichts an meiner Aussage

Gruß

Marc

-- 
Marc Ende
me at e-beyond.de

php::bar PHP Wiki   -   Listenarchive