AW: [php] Zentrale Stammdaten

[Markus Wolff]

Am Tue, 23 Apr 2002 15:58:30 +0200 schrieb Gloss Mathias
<Mathias.Gloss_(at)_start.de>:

> > Jetzt möchte ich noch einen Ortestamm hinzufügen. Dieser Ortestamm soll
> > nicht
> > als Prüfstelle dienen, mehr werden in den Adressen die ID des Ortes
> > gespeichert. Problem ist, wo speichere ich diesen.
> >
> Das macht nicht mal SAP so ... da ist eine Adresstabelle ungefähr so
> aufgebaut:
[...]
> Bei SAP ist in allen Mandantenabhängigen Tabellen die erste Spalte IMMER
der
> Mandant.

Wer hat behauptet, daß SAP was taugt und das man alles so machen soll,
wie SAP?

> > select a.name1, a.name2, a.strasse, o.ort !!!from adresse a, ort o!!!
> > where
> > o.pid = a.pid_ort;
> >
> ? wo ist da das Problem ? Wenn du die !!! weglässt, funktioniert das doch.
> Das Pro-
> blem ist nur, daß in ort alle Orte drin sein können - und auch die können
> sich ändern.

Wenn ich es richtig verstanden habe, ist das Problem eher, daß sich die
Daten in unterschiedlichen Datenbanken befinden...? Das wäre über eine
normale SELECT-Query nicht lösbar.

> > Eine weitere Herausforderung stellt noch dar, das die Lösung unter
meheren
> >
> > DBMS (Oracle, MySQL) laufen soll.
> >
> Datenbank abstrahieren. Mit allen Vorteilen und Nachteilen. Du musst
> mit dem kleinsten Nenner aller Datenbanken arbeiten, und das macht
> noch nicht mal die phplib-DB-Abstraktionsschicht ... Stored Procedures
> usw kannst du dann vergessen, und auch Datenbank-Monitoring über die
> Anwendung.

Neben der phpLib-Abstraktion gibt es übrigens noch diverse weitere
Projekte mit exzellenten Abstraktionsklassen, die auch rege
weiterentwickelt werden (passier bei phpLib eigentlich noch was?).
Beispiele: PEAR::DB, Metabase, ADODB.

Und Verzicht auf spezielle Datenbankfeatures muß nicht sein. Man nehme
eine Abstraktionsklasse für die Datenbank-API - damit hat man schon mal
die Unterschiedlich benamten PHP-Funktionen und kleinere
Inkompatibilitäten erschlagen.

Dann schreibe man sich für die eigentlichen Datenbankzugriffe weitere
Klassen (oder alternativ Funktionsbibliotheken), die mit Hilfe des
Connection-Objekts bestimmte Aufgaben mit dem SQL-Dialekt der jeweiligen
Datenbank lösen und ein passendes Resultset zurückliefern.
Je nachdem, welche Datenbank gerade aktuell ist, wird die Bibliothek
einfach ausgewechselt.

Beispiel:

---[SNIP]---
$db = new AbstraktionsKlasse("Connect-Info");

switch($datenbankTyp) {
        // Beide includefiles definieren eine Klasse mit Namen
        // "datenbankFunktionen"
        case "mysql":
                include_once("mysqlFunktionen.php");
                break;
        case "oracle":
                include_once("oracleFunktionen.php");
}

// Wir wollen einen Datensatz löschen
datenbankFunktionen::loescheEintrag($db,$datensatzID);
---[/SNIP]---

Fertig. Die Funktion "loescheEintrag" ist natürlich in beiden Files
unterschiedlich implementiert, um die Spezialfunktionen der Datenbanken
abzudecken. Wenn im Datenbankmodell das Löschen eines Eintrags aufgrund
von Fremdschlüsseln Löschaktionen in mehreren Tabellen nach sich zieht,
reicht der Oracle-Datenbank ein einfaches DELETE-Statement (dank der
hier möglichen ON DELETE CASCADE Funktion), während die gleiche Funktion
in dem für MySQL gedachten Includefile gleich mehrere DELETE-Statements
abschießt, da Foreign Keys und Trigger nicht vernünftig unterstützt
werden.

Ansonsten würde ich dazu raten, möglichst nicht über mehrere Datenbanken
zu gehen - lieber ein etwas intelligenteres Datenmodell bauen und alles
in der gleichen DB abfackeln - man spart sich viel Ärger und massive
Workarounds.

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