[php] MySQL <-> PostgreSQL

[Sebastian Mendel]

Marc Ende wrote:
> 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.

versteh ich nicht? was willst du damit sagen?

Trigger sind doch klar, die Frage war wo sie nicht ausreichen.


> Ü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.

ja klar, deshalb heißen sie auch 'Views' und nicht 'Writes'


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

??? du sollst doch nicht milliarden von datensätzen holen ... und 
zurückschaufeln, davon redet doch gar keiner ... deshalb gibt es auch 
diese gut bekannte 'abfrage-sprache' mit der man daten gezielt holen 
kann, bzw schreiben kann, um solche sachen ging es aber gar nicht ... es 
ging um Applikationslogik


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

die Datenbank ist aber nicht dafür vorgesehen die Applikationslogik zu 
stellen, sondern die Daten und die Daten-Logik


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

is aber nötig um die Aufgaben des DBA, SE und Programmierers klar zu 
trennen (auch wenn in den meißten fällen dies ein Person ist so kann man 
mit etwas Weitsicht aber nicht davon ausgehen das das immer so bleiben 
wird, erst recht wenn ein Projekt wächst).


irgendwie versteh ich deine Argumentationsfolge nicht, es hat nunmal 
wenig Sinn die verschiedenen Eben einer merhebigen Architektur zu 
vermischen, natürlich bringt es auch immer Nachteile klare Grenzen zu 
ziehen bei einer 3TIER-Architektur, aber die positiven dürften eindeutig 
überwiegen!

Eine reine OOP ist auch weniger performant als eine 
BATCH-Programmierung, aber auch hier nimmt man trotzdem OOP weil die 
Vorteile überwiegen.


-- 
Sebastian Mendel

www.sebastianmendel.de www.warzonez.de www.tekkno4u.de www.nofetish.com
www.sf.net/projects/phpdatetime        www.sf.net/projects/phptimesheet