nicht angemeldet
Halihallo zusammen
[...]
Vielen Dank für eure Antworten. Ich hatte gestern leider keine Möglichkeit mehr darauf
zu Antworten, da mir kurz nach dem Posting das ADSL-Modem entrissen wurde (und zu
Hause hab ich kein Internet, aus gutem Grunde) ;-(
Andreas und Thomas: SHOW KEYS|INDEX FROM ist eine gute Lösung. Ich glaube, dass diese
schon mehr taugen, als die DESCRIBE table, da nicht mehr alle Felder ausgelesen werden
müssen und demnach eine Verbesserung der Performance darstellt.
Alexander: Ja, leider ist das ganze nicht "standardisiert". Das macht es unmöglich, eine
allgemeine Lösung zu erstellen. Man müsste für jede DB (falls derartige
Metainformationen überhaupt auslesbar sind) einen eigenen "Layer" schreiben.
DBIx ist zwar objektorientiert, aber es unterscheidet nicht zwischen Datenbank, Tabelle
und Datensatz, was ich mir wünschen würde. Dein Kriterium wegen Performance (bei
Generalisierungen/Spezialisierungen) ist mir leider bewusst.
Mir schwebt da ein Layer
im Kopf herum, der eine Schnittstelle zwischen Objekten der realen Welt (meinetwegen
Kunden, Rechnung, GekaufteArtikel) und der Datenbankrepräsentation derselben, bildet.
Der erste Schritt hierzu ist ein Datenbankabstraktionslayer, der zwischen Datenbank
(dem "Universum" der Anwendung), den darin enthaltenen Tabellen (Objekte/Klassen) und
deren Tupel/Datensätze (Instanzen von Objekten, z. B. eine bestimmte Rechnung xx des
Kunden yy) und den einzelnen "Objekt-Klassen" (eg. Klasse :KundenRechnung) eine
Schnittstelle erstellt. Die Klassen könnten dann von der entsprechenden Tabelleninstanz
erben, eine Instanz der Klasse von der korrespondierenden Datensatz-Instanz.
Das Kriterium Performance ist wirklich etwas schwierig. Natürlich taugt dieses Vorhaben
nicht für sehr oft schreibende/lesende Zugriffe. Ich glaube aber, dass es vertretbar
wäre, dieses Interface für z. B. Kundendaten zu gebrauchen (worauf eigentlich nur der
Kunde selber und der Administrator zugreift => die Frequenz ist niedrig).
zur gestellten Frage: Alexander hat das Stichwort Performance aufgegriffen, wo ich
mit ihm einverstanden bin, dass die Wrapper die natürlichen Feinde der Performance sind.
Gibt's noch Kommentare/Anregungen/(positive) Kritik zu den anderen Stichwörtern?
- Performance
- Code Reuseability
- komplett und schönes OOP
- Schnelligkeit in programmiertechnischer Umsetzung
- 0815-Programmierer-Hilfe
- Coderedundanz
- UML
oder sind diese im allgemein gehaltenen, noch unspezifizierten Zustand/Beschreibung
nicht beantwortbar?
Viele Grüsse
Philipp