[php] MySQL <-> PostgreSQL

[Andreas Braukmann]

--On Mittwoch, 24. November 2004 18:50 Uhr +0100 Sebastian Mendel <lists at sebastianmendel.de> wrote:

> Marc Ende wrote:
>

> Ich bin immer bemüht klar abgegrenzte Schichten in einer Anwendung zu haben

eben.

> Datenablage  DB-Speicher                           Datenlogik

diese Schicht besteht aus zwei Schichten:

a)    "physikalisches" / normalisierte Datenmodell
b)    konzeptionelles Datenmodell

Die Entkopplung dieser beiden Schichten (eben ueber Trigger
und Stored Procedures) erleichtert sowohl dem DBA wie auch
dem Applikationsentwickler nicht unerheblich die Arbeit.
Das konzeptionelle Datenmodell liefert der Applikation
eine stabile, wohl-spezifizierte Schnittstelle zu den
Daten. Fuer die Entwicklung der Applikation steht ein Daten-
modell zur Verfuegung, dessen Entitaeten und Relationen sich
am Problembereich der Applikation orientieren.
Der DBA hat im physikalischem Datenmodell jederzeit die Moeg-
lichkeit fuer Optimierungen / Anpassungen an aktuelle Beduerf-
nisse. (Normalisierung / Denormalisierung unter Performance-
gesichtspunkten z.B.)


> -------------------------------------------------------------
> Datenzugriff DB-Klassen
>               --------------
>               Objekt-Klassen
> -------------------------------------------------------------
> Anwendung (Datenaufbereitung/Verarbeitung)    Anwendungslogik
> -------------------------------------------------------------
> Ausgabe/UI  Logik
>              --------
>              Vorlagen
> -------------------------------------------------------------
>
>
> Diese Schichten sind möglichst so umgesetzt das an den
>  verschiedenen Schichten verschiedene Leute ohne Kenntnisstand
> über die anderen schichten arbeiten können.

Du sagst es. Und weil Applikationsentwickler in vielen Faellen
z.B. nicht wissen, wie man wann unter welchen Umstaenden welches
SQL-Statement wie hinschreiben muss, damit die Performance nicht
den Bach runtergeht (dass ist bei real existierenden Datenbank-
managementsystemen durchaus ueblich ...), moechte man eine moeg-
lichst schmale, geschlossene Schnittstelle zwischen Datenbank
und Applikation. Die "DB-/Objektklassem" sollten nach Moeglich-
keit nur noch "Datenschubfaecher" fuer Auspraegungen von "Appli-
kationsobjekten" sehen.

SELECT UpdateComplicatedFooBar('key1', 'key2', ..., 'att1', 'att2' ...)


Schlussendlich ist es natuerlich Streit um des Kaisers Bart,
wohin man das konzeptionelle Datenmodell legt (Hauptsache, es
gibt eines).
Wenn man eine duenne (von allen verwendeten Client-Applikationen
verwendbare) Schicht um das physikalische Datenmodell legen kann,
ist dies auch sinnvoll. Es besteht dann aber auch die Gefahr, dass
mehr Daten zwischen Datenbanksystem und Applikation fliessen als
eigentlich notwendig waere.


-Andreas