Und genau das ist der Irrtum: Es geht eben genau darum, NexusDB oder nicht! Weil NexusDB - wie bereits von mir erwähnt - meines Wissens die einzige
DB ist, die in einer einzigen ausführbaren Datei sowohl Client-Server-Datenbankserver sein kann, als auch ganz normales Anwendungsprogramm. Im Einzelplatzmodus und im Netzwerkmodus, ohne Installation, genauso wie vom TE gewünscht.
Und genau deshalb scheidet doch NexusDB aus: Wer so eine Architektur anbietet, *kann* einfach nichts taugen. Es wäre sinnvoller, sich an einer offenen Diskussion um robuste, vernünftige und nachhaltige Architekturen zu beteiligen und den TE eventuelle von dieser absurden Idee abzubringen.
Zitat:
Der TE wird Gründe haben, nicht mit dem Flieger zu fliegen, sondern mit dem Fahrrad fahren zu wollen.
So, wie es aussieht, fällt ihm außer dem Flieger nichts ein, das Fahrrad bekommt er ja von Dir eingeredet. Es ist nicht sinnvoll, ihm das einzige Fahrrad schmackhaft machen zu wollen, das ein Zelt und Kocher auf dem Gepäckträger montiert hat und mit dem es möglich ist, auch während der Fahrt eine warme Mahlzeit zu sich zu nehmen, während man Fussi gucken kann. Du musst zugeben, das ein derartiges Fahrrad zwar ein Alleinstellungsmerkmal besitzt und durchaus fahren kann, aber im realen Einsatz starke Defizite aufweist: Ist das Zelt kaputt, wird man nass. Fällt der Kocher aus, verhungert man (oder isst trocken Brot mit Schmalz). Und geht der Fernseher hopps, ist eh alles egal. Und wenn das Fahrrad mal kaputt geht, wird man pitschnass, erfriert, verhungert und kann -was besonders grausam ist- die weiteren Spiele der dt. Mannschaft nicht erleben.
Ist es nicht praktischer, die einzelnen Komponenten *separat* zu verwenden? Also ein (austauschbares) Zelt, einen (upgradefähigen) Kocher und einen (nach der WM vertickbaren) Fernseher?
Also: NexusDB kann das. Middleware+AccessDB auch, nebenbei bemerkt. Aber man macht es nicht, Stichwort: "SOA" in seiner allgemeinsten Form.