Mit NexusDB arbeiten wie mit der BDE

[mm1256]

Zitat:

Es geht nicht um Nexus oder nicht, sondern dedizierter Server ( von mir aus mit NexusDB) oder nicht!

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.

Um Ihren Sprachgebrauch zu verwenden: Der TE wird Gründe haben, nicht mit dem Flieger zu fliegen, sondern mit dem Fahrrad fahren zu wollen. Es gibt einen sehr gut ausgebauten, sicheren und komfortablen Radweg nach China. Wenn dieser auf Ihrer Landkarte nicht eingezeichnet ist, macht es dann Sinn, mit Ihnen diesen Weg diskutieren?

[Dejan Vu]

Zitat von mm1256:

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.

[mm1256]

Zitat:

Und genau deshalb scheidet doch NexusDB aus: Wer so eine Architektur anbietet, *kann* einfach nichts taugen.

Ich bin begeistert von so viel Fachkenntnis

[Zoot]

Zitat von Dejan Vu:

Wer so eine Architektur anbietet, *kann* einfach nichts taugen.

Ich wiederhole mein "Aha".

Dogmen können die Welt vereinfachen.

[Sherlock]

Zitat von mm1256:

Zitat:

Und genau deshalb scheidet doch NexusDB aus: Wer so eine Architektur anbietet, *kann* einfach nichts taugen.

Ich bin begeistert von so viel Fachkenntnis

Würdest du Deine Kommentare mit etwas weniger Bissigkeit von Dir geben, würde man eventuell vernünftiger miteinander reden können.

<SARKASMUS>Wenn man wirklich Ahnung hat, nimmt man ohnehin Oracle.</SARKASMUS>

Sherlock

[Dejan Vu]

Zitat von mm1256:

Ich bin begeistert von so viel Fachkenntnis

Ich wusste, ich kann dich überzeugen. Vielleicht denkst Du ein wenig über das Beispiel mit dem Übernachtungskochfernsehfahrrad nach, vor allen Dingen hinsichtlich der Robustheit gegenüber dem Ausfall einzelner Komponenten.
Und dann würde ich mir einfach mal auch darüber Gedanken machen, warum diese Architektur nicht weit verbreitet ist. Eigentlich gar nicht.

Zitat von Zoot:

Ich wiederhole mein "Aha". Dogmen können die Welt vereinfachen.

Wenn es welche wären. Die naheliegende Interpretation wäre jedoch: 'Rethorische Übertreibung', aka 'Hyperbel'. Übrigens wäre der zweite erhellende Satz im ersten Post wirklich brauchbar gewesen, denn für ein Dogma hätte ich auch nur ein 'Aha' bzw. ein 'So so' übrig

[arnof]

Zitat von Captnemo:

Hallo,

ich hab mir grad im Internet die NexusDB angeschaut. Bin mir aber nicht sicher, ob sie das, was ich machen will, so kann. Vielleicht weiß das ja einer von euch.
Ich möchte mit der NexusDB quasi so arbeiten, wie mit der BDE.

Also eine DB erstellen, die ohne Serverkomponente auskommt, wo von verschiedenen Rechner zugegriffen werden kann, und die Tables / Datensätze gesperrt werden können. Geht das so ohne weiteres mit der NexusDB? Oder ist da eine andere DB besser für geeignet?

Ziel ist es, eine DB zu haben, die
a) ohne große Installation auskommt, und am besten alles ins Prog implementiert werden kann.
b) das lokale Arbeiten mit einer DB möglich ist (Einzelplatz)
c) aber auch z.B. die DB auf einem Netzlaufwerk/UNC abgelegt werden kann, so dass mehrere Rechner zeitgleich darauf zugreifen können.

Ich habe ADO Componenten so umgeschrieben das ich auf MSSQL und MYSQL wie mit der BDE zugreifen kann, d.h. also TTABLE via Index und Setrange/Findkey usw. TQuerys übersetzt entsprechende Sachen in die jeweilige Datenbank z.B. True/False, Datumsformatierung, usw

[Daniel]

Wer von Euch bezahlt denn die Realisierung dieses Projekts und steht für das Endergebnis gerade?
Es ist in Ordnung, seine Bedenken anzumelden und auf andere - möglicherweise tragfähigere - Lösungen hinzuweisen. Aber sich gegenseitig die Kompetenz abzusprechen, ohne die kompletten Rahmenbedingungen eines Projektes zu kennen, ist zu kurz gegriffen. Ich habe mittlerweile genug Kundenprojekt gesehen, die fürchterliche Aspekte hatten und diese dennoch trotz besseren Wissens aus verschiedenen Gründen vorerst so beibehalten werden mussten.

Ich denke, dass Ihr den Fragesteller nun hinreichend für etwaige Schwächen seines Ansatzes sensibilisiert habt und mehr ist dazu auch kaum zu sagen.

[Dejan Vu]

Zitat von Captnemo:

Hallo,
Ziel ist es, eine DB zu haben, die
a) ohne große Installation auskommt, und am besten alles ins Prog implementiert werden kann.
b) das lokale Arbeiten mit einer DB möglich ist (Einzelplatz)
c) aber auch z.B. die DB auf einem Netzlaufwerk/UNC abgelegt werden kann, so dass mehrere Rechner zeitgleich darauf zugreifen können.

Darum geht es.
a) wird durch Firebird, SQL-Server Express mit Silent Install erschlagen, wobei ich 'ohne große Installation' wörtlich nehme. Vom Installationsaufwand ist Firebird sicherlich vorzuziehen (subjektiv)
b) Ist implizit, das geht mit jedem RDBMS, das lokal installiert ist.
c) Ja, wobei die genannten Einschränkungen ohne Server gelten (unsicher bei gleichzeitigem Zugriff per design)

Über die vorgeschlagene Lösung, eine DB-Engine in die Applikation mit einzubinden wurden alle Argumente ausgetauscht.

Vielleicht geht es jetzt wieder sachlich weiter.

[Sir Rufo]

Ich möchte mich in das HickHack hier nicht einmischen (ist aber lustig zu lesen ), aber sollte es einer Anwendung bei der Persistenz-Schicht nicht völlig egal sein wie das da passiert und wer das mit wem wo speichert - Hauptsache es wird?

Ok, irgendwann geht man da dran, aber dann wird nur noch die eine oder andere oder mehrere (je nach Einsatzgebiet) konkrete Persistenz-Schicht implementiert und je nach Gusto, Vorliebe und Geldbeutel wird das eine oder andere System genommen.