nicht angemeldet
Hallo Frank,
Danke erst einmal für Deine Anregungen.
bei einer Verbandelung von .Net Client-Applikation (die soll ja so bestehen bleiben) mit einem Java-Applikationsserver, würde ich vorab die Interoperabilität überprüfen - Datentypen, Datenaustauschprotokolle (SOAP??).
Das ist mir bewusst. Gerade SOAP neigt ja dazu, bei größerer Last ein Problem zu werden, das XML an sich geschwätzig ist und somit zusätzliche Last in der Kommunikation und an den Endpunkten derselben erzeugt (Stichwort Serialisierung/Deserialisierung).
Grundsätzlich ist es nicht schlecht sondern sogar ganz praktisch, eine gewisse Menge Logik in der Datenschicht zu haben, die die Datenhaltung unterstützt. (Das verstehen aber einige selbsternannte OO-Software-Projektleiter-Helden nicht, die möchten gern alle Daten gleich und immer in .Net Objekten haben. Ich hoffe, dass diese bald aussterben ;))
Das möchte ich nicht kommentieren;-)
Aber Du triffst den Nagel auf den Kopf, da es auch bei uns die beiden Lager gibt, die einen, die meinen "OO wird'S schon richten" und die anderen die den Standpunkt haben "Nur die Datenbank ist das einzig Wahre".
Ich allerdings vertrete den Standpunkt "Kommt darauf an". Mein Problem bei der Sache ist, dass ich das noch nicht so richtig Anschätzen kann. Ich bin zwar der Überzeugung, dass man mit jeder von mir angesprochenen Architektur das Problem lösen kann, allerdings weiss ich noch nicht, welche die für uns optimale ist.
Deshalb frage ich ja hier nach, da sich immer einige hier herumtreiben, die scheinbar schon einiges an Erfahrung mit den jeweiligen Technolohgien haben.
Zurück zum Thema: Was für Operationen tut ihr so in diesen PL/SQL SPs?
Grundsätzlich alles, was irgendwie die Daten manipuliert. Es gilt, dass keine Clientanwendung (GUI und Hintergrundprozesse) direkt DML-Statements absetzen dürfen.
Die Funktionalität reicht von simplen INSERT/UPDATE/DELETE-Prozeduren bis hin zu komplexen Verarbeitungen von vielen Datensätzen.
Stichwort Applikationsserver: Was hättet ihr an Infrastrukturaufgaben, die abgefackelt werden könnten:
- Logging
- Access Right Managment
- Auditing
- Historizing
Wo sind diese Dinge momentan implementiert?
Das ist unterschiedlich. Jedes beteiligte Subsystem hat bspw. sein eigenes Logging. ARM wird über das GUI-System erledigt, Auditing z.T. auch. Historizing machen, falls notwendig, die Subsysteme selbst.
Stichwort Datenbank: Wie gedenkt ihr die PL/SQL Sachen zu entflechten? Steht ein Datenbank-Refactoring ebenfalls zur Debatte?
PL/SQL soll, so ist die Idee, vollständig von der OO-Implementierung abgelöstt werden. Und ein Redesign der DB ist Teil des Projekts.
Grüße
Klaus