Hi Oreaden,
Zitat von
Oreaden:
Mein Orakle lässt mich leider in stich
.
Was mich interessieren würde ist, wer ist denn deine Zielgruppe? Ist das für eine Komponente welche x tausendfach installiert wird oder ist das eine fertige Anwendung deren Entwicklung rein in deinen Händen liegt?
Letzteres.
Zitat von
Oreaden:
Je nach Art der Zielgruppe gibt es einen anderen Lösungsansatz. Für eine Komponente, welche ein kleines Logging enthalten soll, ist eine Datenbank welcher Art auch immer absolut oversized. Da kämme dann eher ein Flatfile oder 'n
XML in betracht. Ist das eine Anwendung, welche auch schon eine bestimmte größe aufweist und zudem Funktional einiges mitbringt, wird da sowieso eine Datenbank vorhanden sein. Hier kann man die Beschränkung der Datensätze einfach über einen Trigger realisieren.
Guter Punkte mit dem Trigger!
Zitat von
Oreaden:
Tut mir leid, daß ich nicht mehr liefern kann, aber ohne Orakel kann ich nur die
benutzen und sie ist doch etwas unzuverläßig.
Kein Problem, freu mich ja, daß Du soviel Text jetzt schon mitgemacht hast
Man kann leider nicht immer ins Detail bei kommerzieller Entwicklung.
Das ganze ist ein Tool, welches Daten abholt und verarbeitet. Eingangsdaten
XML werden per XSLT aufbereitet, in einer
DB gespeichert und Weiterverarbeitet (ebenfalls XSLT, Druck etc.pp.). Es kann als
GUI laufen, wobei dann die ganze Arbeit von der
GUI gemacht wird und dem Benutzer nachträgliche Kontrolle und Weiterverarbeitung ermöglicht, oder als Kombination einer
GUI/Service. Dies auf identischer Codebasis (Datenmodule etc).
Bei Nutzung der Service/
GUI-Kombi verlagert sich dann die Automatisierung in den Service. Das ganze mit austauschbarer
DB (im Falle einer
GUI-Only Nutzung mit SQLite3 als
DB zum portablen Einsatz).
@Michael: Die Idee gefällt mir. Leider stehen soweit ich es eben abprüfen konnte, wirklich keine fertigen Libraries zur Verfügung. Da die Anwendung zu 98% steht, wäre es jetzt sehr aufwändig hier selbst etwas zu bauen.
Ich verfolge gerade aber eine andere Idee. Wegen der geringen Größe der
DB könnte ich per Default auf SQLite3 setzen. Das ganze könnte ich an DataSnap 2009 per Interface-Klasse binden. Ich stelle dann zwei Klassen für Haupt-
DB und Log-
DB bereit (keine zweite Tabelle, das soll von den Businessdaten getrennt gespeichert werden).
Über die DataSnap Server geh ich im Falle einer Service/
GUI als C/S
DB. Im
GUI-Only Fall dann als LocalConnection.
Damit schlage ich zwei Fliegen mit einer Klappe: Selbe Datenbankbasis für Service und Service/
GUI und keine
IPC Notwendigkeit.
Ich muß nur mal sehen, ob es bei DS 2009 auch sowas wie Push-To-Clients gibt.
Gruß Assertor