[php] MySQL <-> PostgreSQL

[Marc Ende]

Sebastian Mendel wrote:

>>> Mir fehlt etwas die Fantasie zu verstehen wo für die Datenkonsistenz
>>> Trigger nicht ausreichen in normalisierten DB?
>>
>
> versteh ich nicht? was willst du damit sagen?

Tja, vielleicht hab ich deinen Satz dann nicht richtig verstanden.

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

Trigger sind im allgemeinen Übersichtlich. Allerdings war hier wohl eher 
Stored Procedure gemeint, oder?

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

Stimmt, bei Php sind die Daten ja immer gleich alle da.... Ich vergaß, 
daß die Seiteneffekte, wie Datenübermittlung von und zur Applikation nur 
bei anderen Sprachen existieren :)

>> 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")
>
> Duplizierung von Code wird durch die Verwendung von Klassen
>
> die Datenbank ist aber nicht dafür vorgesehen die Applikationslogik zu 
> stellen, sondern die Daten und die Daten-Logik

Tier 2 ist Businesslogik, teilweise gehört die Datenbank eben auch dazu. [1]

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

Ist vielleicht ein Nebeneffekt von Views, den man mißbrauchen kann. 
Allerdings nicht Sinn und Zweck. Views sind keine Abstraktionslayer oder 
Teile eines "Datenbankinternen MVC".

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

Der Logische Teil der Datenbanken sind nach allgemeiner Lehre eben 
bestandteil des 2. Tiers. Der dritte Teil ist die Physikalische 
Datenbank. Im übrigen wird auch dabei davon ausgegangen, daß 
Validierungen u.a. der Integrität eben auch Bestandteil des 3. Tiers sind.

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

Wage These, über die ich nicht diskutieren werde.

Viele grüße

Marc

[1]http://www.dfpug.de/konf/konf_1998/09_tier/d_tier/d_tier.htm