Mit NexusDB arbeiten wie mit der BDE

[Dejan Vu]

Zitat von Sir Rufo:

... aber sollte es.. nicht völlig egal sein wie das da passiert und wer das mit wem wo speichert - Hauptsache es wird?

Stimmt. Aber irgendwann muss man sich festlegen, 'wie das da passiert'. Und die Problematik ist schon erstens der normale Alltag, aber zweitens auch eine Herausforderung, da offensichtlich viele Wege zum Ziel führen und keine (ach so blödsinnige) Lösung bisher den dritten Weltkrieg ausgelöst haben.

[p80286]

Ich hab die Gelegenheit ergriffen und mich mal -oberflächlich- über NexusDB informiert.
Da ist immer ein "Server" im Spiel der sich um die DB kümmert (so wie bei FB). Also vom Grobkonzept her genau das gleiche. Bleibt die Frage BDE-Ersatz (als solcher ist NexusDB wohl konzipiert) und "eine Datei auf die gaanz selten zugegriffen wird". Diese Anforderung kann man nur dann ruhigen Gewissens umsetzen, wenn sichergestellt ist, daß nur ein "Client" zu einem Zeitpunkt schreibend zugreift.
Und das diese Anforderung hier sehr kritisch gesehen wird ist für mich sehr gut nachvollziebar.

Gruß
K-H

[Sir Rufo]

Zitat von Dejan Vu:

Zitat von Sir Rufo:

... aber sollte es.. nicht völlig egal sein wie das da passiert und wer das mit wem wo speichert - Hauptsache es wird?

Stimmt. Aber irgendwann muss man sich festlegen, 'wie das da passiert'. Und die Problematik ist schon erstens der normale Alltag, aber zweitens auch eine Herausforderung, da offensichtlich viele Wege zum Ziel führen und keine (ach so blödsinnige) Lösung bisher den dritten Weltkrieg ausgelöst haben.

Nein, man muss sich eben nicht festlegen. Es reicht wenn die Persistenz-Schicht sich so verhält, wie vereinbart. Wie diese Schicht das dann macht und erledigt ist (der Anwendung) egal.

Heute finde ich SQlite toll, morgen aber vielleicht NexusDB und übermorgen kommt ein Kunde und will die Ultra-Trallala-DB verwenden. Dann wird genau dafür eine konkrete Persistent-Schicht gebaut, durch den Persistenz-Interface-Unit-Test gejagt und der Drops ist gelutscht.

[Dejan Vu]

Zitat von Sir Rufo:

Wie diese Schicht das dann macht und erledigt ist (der Anwendung) egal.

Installieren (siehe Punkt a,b,c) muss man schon irgend etwas. Und dann muss man sich festlegen. Denn eine Mehrbenutzerumgebung mit Netzdateien, bei denen das OS die Konsistenz nicht versichern kann, sind keine ernsthafte Lösung.

Zitat:

Dann wird genau dafür eine konkrete Persistent-Schicht gebaut, durch den Persistenz-Interface-Unit-Test gejagt und der Drops ist gelutscht.

Wenn man mit 08/15-Performance und -Möglichkeiten leben kann, dann ist der Drops gelutscht. Ansonsten muss man sich schon festlegen (Stichwort Massenupdates, ETL usw.). Aus Kundensicht ist es -im Gegenteil- sehr sicher, das sich da nix mehr ändert, wenn man vorher einmal nachgedacht hat. Und es ist auch besser so.

Aus Anwendungssicht hast Du ja Recht, aber hier geht es imho ausnahmsweise nicht um ORM. Obwohl.... wieso eigentlich nicht?

[Captnemo]

Also, dass ihr euch hier bekriegt lag natürlich nicht in meiner Absicht Dient auch nicht Zweck. Also....keep cool

Zurück zum Thema:

Tatsächlich war mein Anspruch der, dass ich wirklich ähnlich der BDE auf eine Filebased-DB zugreifen möchte. Ob das letztlich über vollständig Embedded in der EXE geschehen muß ist ja noch mal was anderes (ist ja bei der BDE auch nicht so). Aber ich möchte in dem Projekt ohne Server-DBS, Serverprozess oder sonstiges auf dem Server auskommen.
Nennen wir mal ein anderes Beispiel, z.B. VoxPro. Das ist ja ähnlich, und auf dem Server läuft auch keine Serverengine.

Was jetzt die Performance, Datenbankgröße oder Datensicherheit angeht, so sind mir die Nachteile durchaus bewußt. ABER: bei dem Projekt handelt es sich 1.) um eine Programmierung für einen Kunden und auch ausschließlich nur für diesen Kunden, 2.) die Datenmenge wird sich nicht verändern, die Anzahl der Clients wird sich nicht verändern und 3.) das Budget für dieses Projekt ist sehr klein, und läßt keinen Spielraum für zusätzliche Anschaffungen.
Weiterhin sollte es möglich sein, ohne Serverzugriff die DB auf andere Pfade zu verschieben (was ja bei der BDE oder VoxPro auch ohne Probleme möglich ist).

Was den Server angeht, so gibt es durch aus Unternehmen, die z.B. den Server von Vertragspartnern aufgestellt bekommen. Und es gibt dort tatsächlich Wartungsverträge, die Fremdprodukte untersagen, was dann heißt, dass das Unternehmen auf diesem Server nichts installieren dürfen, sonst verlieren sie ihren Supportanspruch. In solchen Fällen sind solche Sachen durchaus sinnvoll. Deswegen gleich einen anderen Server daneben zu stellen, kann man machen....muß man aber nicht. Will der Kunde ggf. auch nicht. Denn dieser muß auch wieder gesichert werden. Und wenn man dann das DBS auf einem Client realisiert, dann sind wieder alle davon abhängig, dass keiner zum Feierabend aus versehen diesen herunterfährt.
Also ich finde ja, dass BDE o. ä. durchaus ihre Daseinsberechtigung hat.
Ich bin jetzt tatsächlich nicht ganz sicher, aber wird die BDE unter Win 8.1 64-bit überhaupt unterstützt? Ich glaube nicht.

[Sir Rufo]

Kann man zwar nachvollziehen ändert aber nichts an der Realität und die sieht nun mal so aus, dass ein Filelock auf einer Datei im Netzwerk nicht zuverlässig funktioniert. Funktioniert zwar meistens aber eben nicht zuverlässig immer. Das ist und bleibt der Knackpunkt bei allen Systemen, die gleichzeitig auf eine Datei im Netzwerk zugreifen möchten.

Wenn man das weiß, und der Kunde das so wünscht, dann ist es nur fair den Kunden darauf hinzuweisen um das Thema Datensicherheit/Datensicherung entsprechend hervorzuheben.

[Captnemo]

Naja, du hast wohl recht, dass will ich nicht bezweifeln.

Aus meinem Kundenkreis kenne ich einige Beispiele, die mit BDE/Paradox bzw. VoxPro arbeiten. Und das sehr erfolgreich, performant und fehlerfrei. Da wäre z.B. ein Kfz-Programm, welches von einem großen Teilelieferanten vertrieben wird. Als DB wird VoxPro verwendet. Läuft im Netzwerk absolut problemlos, und in meinem Fall mit ca. 20 Usern. Datenbestand ist auch nicht gerade klein mit ca. 5000 Kunden, 25000-30000 Artikelstamm und ca 3000-4000 Rechnungen im Monat. Das ist jetzt ein halbes Jahr in Betrieb ohne Geschwindigkeitseinbußen und ohne irgendwelche Probleme. Da ist schon ganz schön Bewegung drin. Wenn die das könne.....
Und ich war bei der Erstinstallation dabei...keinerlei Installation auf dem Server, lediglich ein gemeinsames Netzlaufwerk wird benötigt.
Klar, dort werden neben dem entsprechenden Programm auch noch Runtimes installiert, aber mit sowas könnte ich ja leben.

Ich hätt auch noch ein anderes Beispiel mit einer Zahnarztsoftware, die was ihren Marktanteil angeht, ihres gleichen sucht. Arbeiten komplett mit DBase oder Paradox (weiß ich jetzt nicht ganz genau), aber vollständig Filebase ohne jedliche Serverinstallation.

Selbst mit einer gewissen Fehlertoleranz könnte ich noch leben.

Es gibt ja auch z.B. Absolut Database von ComponentACE. Bieten auch Multiuser und Filebased. Ich hatte gehofft, dass es evtl. auch was Free gibt, was ähnliche Anforderungen unterstützt.

Mir ist vollkommen klar, dass solche Datenbanken nicht das Optimum darstellen, aber in oben genannten Beispiel war vorher ein Pervasive-SQL-Server in gleichem Umfeld in Betrieb, der in keinster Weise schneller war.

Es gibt eben nicht nur große Unternehmen, die mit eigener EDV-Abteilung ihre eigene Server-Farm betreiben. Es gibt auch viele, viele Kleinunternehmen, die eben nur einen Server (wenn überhaupt) stehen haben, mit dem Hintergrund "Der war schon teuer genug". Und über die Zeit laufen auf diesem diverse DBS. Die eine Software bringt ihren Microsoft SQL Express mit, die nächste ihren SQL Anywhere, dann kommt der nächste Teilekatalog mit einer MySQL, oder Postgre um die Ecke und Schwups laufen auf dem Ding drei, vier SQL-Engines. Da wird schon mal der Speicher eng.
Meist habe diese Firmen keinen eigene Admin, manchmal auch nicht mal einen Admin, da macht das irgendein Kollege, der sich etwas auskennt.

Ich will mit meinem Projekt ein paar Daten erfassen, wie gesagt nix großes. Es soll einfach, klein und billig sein. Wenn das bei großen Projekten läuft, warum sollte ich das nicht in Betracht ziehen?

[Dejan Vu]

Zitat von Captnemo:

Nennen wir mal ein anderes Beispiel, z.B. VoxPro. Das ist ja ähnlich, und auf dem Server läuft auch keine Serverengine.

Also wenn Du mit VoxPro Visual FoxPro vom Microsoft meinst, dann muss ich da widersprechen: VoxPro arbeitet mit ODBC und damit mit jedem RDBMS.

Zitat:

Also ich finde ja, dass BDE o. ä. durchaus ihre Daseinsberechtigung hat.

Ja, aber (ich sage es mal sehr laut) DIE DATENBANKEN/DATENDATEIEN WIRST DU DIR REGELMÄßIG ZERSCHIESSEN!. Dein Beispiel mit 'VoxPro': Bei einem meiner Kunden hat es die DB so 2x im Jahr zerschossen. Lustigerweise merkt man das nicht immer, es fehlen einfach nur Daten. Das ist dann umso lustiger, je geringer die Rechnungen infolge Datenverlust ausfallen. Deine Argumentation ist so wie die des Autofahrers, der sagt: 'Ich fahre schon immer ohne Gurt und lebe noch, also taugt er nichts'.

Edit: Man fragt sich, wieso immer noch Programme in der Architektur, wie von dir beschrieben, verkauft werden.

Zitat:

Ich bin jetzt tatsächlich nicht ganz sicher, aber wird die BDE unter Win 8.1 64-bit überhaupt unterstützt? Ich glaube nicht.

Mit seeehr viel Knowhow und unter bestimmten Umständen: Ja. Aber wozu? Die BDE ist doch eh totaler Müll.

Ich behaupte mal; Es gibt keine Desktop-DB, die eine Datei im Netz zuverlässig vor Inkonsistenzen und allgemeiner Zerschrotung schützt. Und deshalb raten dir hier alle zu einem richtigen RDBMS, welches sich auf die Datei setzt und exklusiv den Zugriff steuert.

Wenn Dir das egal ist, und die Daten sowieso nur sehr sehr selten parallel von mehreren Clients beschrieben werden, dann nimm Access oder SQLite, das knallt nur bei hoher Last, also wenn die DB sehr oft parallel bearbeitet wird.

Übrigens: Das alles hat mit 'der BDE' nun wirklich überhaupt nichts zu tun. Die war nur ein ziemlich grausliger Versuch, die unterschiedlichen Provider unter einen Hut zu bringen. Fälschlicherweise wird die BDE mit Paradox in Verbindung gebracht, einer noch größeren Krankheit als die BDE.

[jobo]

[OT]

Zitat von Sherlock:

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

Hab ich da Oracle gelesen?
Und war das jetzt quasi doppelte Verneinung?!

[/OT]

[Captnemo]

Zitat von Dejan Vu:

Also wenn Du mit VoxPro Visual FoxPro vom Microsoft meinst, dann muss ich da widersprechen: VoxPro arbeitet mit ODBC und damit mit jedem RDBMS.

Wie VoxPro arbeitet weiß ich nicht, hab ich mich noch nie mit beschäftigt. Ich hatte lediglich seinerzeit mal mit einem DB-Viewer eine der Dateien geöffnet, weil wir wissen wollten welche Daten darin beherbergt werden, und damals nannte der Viewer als DB-Typ VoxPro. Deswegen bin ich davon ausgegangen.

Zitat von Dejan Vu:

Dein Beispiel mit 'VoxPro': Bei einem meiner Kunden hat es die DB so 2x im Jahr zerschossen. Lustigerweise merkt man das nicht immer, es fehlen einfach nur Daten. Das ist dann umso lustiger, je geringer die Rechnungen infolge Datenverlust ausfallen.

Kann ich so nicht bestätigen. In meinen beiden Beispielen laufen die sehr stabil und definitiv Datenverlustfrei. Im Falle des Zahnarztes seit 9-10 Jahren mit 0 Ausfällen, Dateninkonsistenzen oder Datenverlusten. Und die prüfen ihre Daten sehr akribisch.

Ich hatte auch mal einen Kunden, der so alle paar Monate seine Exchange-Datenbank komplett zerschossen hatte. Wir haben lange nach einem Fehler gesucht, aber keinen gefunden. Das war noch zu den Exchange 5.5 und NT4-Zeiten. Nach dem vierten mal haben zufällig herausgefunden, dass ein Mitarbeiter (im Auftrag des Chef's) alle 3 Monate den Server mit einem Defragmentierer bearbeitet hat, natürlich wärend der Exchange online war. Der Chef hatte das natürlich vergessen.
Aber das gehört hier nicht hin

Zitat von Dejan Vu:

Edit: Man fragt sich, wieso immer noch Programme in der Architektur, wie von dir beschrieben, verkauft werden.

Naja, was soll ich sagen....scheint bei denen wohl doch gut zu funktionieren. Ich könnt noch mehr Beispiele aus der Praxis aufzählen, wo derartige System im Einsatz sind. Und merkwürdigerweise laufen die Dinger und laufen. Warum kann ich dir nicht sagen. Ich kann aber nur von meinen Kundenkreis sprechen.

Zitat von Dejan Vu:

Wenn Dir das egal ist, und die Daten sowieso nur sehr sehr selten parallel von mehreren Clients beschrieben werden, dann nimm Access oder SQLite, das knallt nur bei hoher Last, also wenn die DB sehr oft parallel bearbeitet wird.

Darauf wird es wohl hinauslaufen.