Schnelle Datenbank ohne Server und ohne BDE

[Furtbichler]

Zitat:

Zitat von DeddyH (Beitrag 1144456)

Gegenfrage: wieso keine DB?

Wir entwickeln auch Anwendungen für XP Embedded, wo man mit minimalem Footprint auskommen sollte, nach dem Motto "Wo viel wie nötig, so wenig wie möglich"

[BUG]

Zitat:

Zitat von jobo (Beitrag 1144466)

Dazu sollten minimale Voraussetzungen ausreichen, es muss robust und performant sein.

Also wenn es um gute Auswertbarkeit geht mit einer relativ robusten Datenbank geht, würde ich sqlite zumindest in Betracht ziehen.
Und die Geschwindigkeit sollte für deine 2-4 Inserts pro Sekunde ausreichen. Das ist könnte man auch mal testen.

[p80286]

Zitat:

Zitat von Jackie1983 (Beitrag 1144444)

- Unser Dienst greift alleine auf die DB zu.
- Das suchen erfolgt in einem anderem Programm, Datenaustausch per socktes.

Da stimmt etwas nicht.
Entweder greift eine Anwendung exclusiv auf einen Datenbestand zu, dann gibt es (zur Laufzeit) keine Möglichkeit auf den Datenbestand von einem anderen Programm aus zuzugreifen, oder aber es gibt mehr als ein Programm die auf den Datenbestand zugreifen. Dann ist aber Essig mit Embedded.

Eine weitere Möglichkeit wäre es allerdings, wenn mehrere Programme abwechselnd zugreifen.
Dann könnte man auch gleich bei der Textdatei als Logdatei bleiben und für die Auswertung mit einer/einem Kopie/Datenbankimport arbeiten.

Gruß
K-H

[Sir Rufo]

Das mit

Zitat:

Zitat von Jackie1983 (Beitrag 1144444)

- Es sollte keine Anwendung / Server / Dienst installiert werden. Dll etc ist egal.

verstehe ich das richtig, dass keine Fremd-Anwendung/-Server/-Dienst installiert werden soll?

Ich würde dann einmal (schon wieder ;) ) mORMot in den Raum werfen.

SQLite-basiertes ORM und hat packt alles in eine Anwendung. Keine DLL.

Und der Clou, im Handumdrehen auch als Client-Server-Lösung fertig (den Server baut man sich selber)!

[sh17]

HAb jetzt hier nicht alles durchgelesen, aber wenn es nur ums schreiben von Datensätzen geht, wäre BigTable auch eine Alternative. Ist u.a. in mORMot enthalten und kann separat genutzt werden. Das sollte genug Geschwindigkeit sein.

Zitat:

Zitat von Sir Rufo (Beitrag 1144564)

Ich würde dann einmal (schon wieder ;) ) mORMot in den Raum werfen.

Warum machst Du eigentlich ständig Werbung dafür ? :)

[Jackie1983]

Zitat:

Zitat von p80286 (Beitrag 1144557)

Da stimmt etwas nicht.
Entweder greift eine Anwendung exclusiv auf einen Datenbestand zu, dann gibt es (zur Laufzeit) keine Möglichkeit auf den Datenbestand von einem anderen Programm aus zuzugreifen, oder aber es gibt mehr als ein Programm die auf den Datenbestand zugreifen. Dann ist aber Essig mit Embedded.

Ähm wieso nicht? Programm eins greift auf die DB. Programm zwei greift auf die Daten per sockets die im Programm 1 enthalten sind. Also greift nur ein Prog. auf die DB :).

Was ist festgestellt habe, wenn die DB größer wird (beim test gerade mal 50mb, was nichts ist) wird das öffnen etwas dauern. Genauso wird viel speicher zu verfügung gestellt je größer die DB wird...

[Furtbichler]

Wenn die Daten wirklich live ausgewerten werden sollen (und nicht auf Knopfdruck zwischendurch irgendwann), müsste man eine richtje DB in Betracht ziehen. Euer Service wird sich dann exklusiv auf die DB setzen (z.B. mit Firebird embedded, SQLite o.ä.).

Queries kommen als SQL-Befehl per Socket durch, werden ausgeführt und das Ergebnis zurückgeschicht.

Da ist zwar jetzt nicht so der Unterschied zu einem DB-Server (weil es ja eigentlich einer ist, den ihr da schreibt), aber WTF. Wenn die Vorgabe so ist.

Man könnte auch ein FB/SQL-CE...

Zitat:

Zitat von Wikipedia

...Ein Anwendungsgebiet sind z. B. Programme zur Analyse von Logdateien. Diese lesen eine Logdatei ein, zerlegen sie und speichern sie intern als Datensätze in einer Tabelle. Durch den Zugriff mittels SQL auf die Daten ist ein nahezu beliebiges Sortieren und Filtern möglich.

SQL CE wird von Microsoft kostenlos angeboten und verfügt über eine native 64-Bit Unterstützung.

[Mavarik]

Hallo!

hmm... Leute,Leute...

Warum wollt Ihr immer mit Kanonen auf Spatzen schiessen?

2-3 Inserts pro Sekunden... Lächerlich....

Datenrecords speichern mit Blockwrite... Und kleinen BTree Index selber aufbauen...
Bischen RAM, bischen QSort, ggf. bischen Thread - in einer Stunde zusammen "gehackt"...
Und schon kann man paralell noch das Apfelmänchen berechnen... :stupid:

Grüsse Mavarik

[Furtbichler]

Hi Mavarik,
Das ist keine produktive Vorgehensweise, denn man ist nicht in der Lage, innerhalb einer Stunde etwas zusammenzuhacken, das auch garantiert funktioniert. Wie hältst Du es mit der Freispeicherverwaltung (alte Datensätze werden kontinuierlich gelöscht), dem Schutz gegen Ausfall, Datenkonsistenz?

Etwas heute in einer Stunde zusammenzuhacken bedeutet, das man morgen eine Woche investiert, um den Müll zu entwanzen.

Du kannst das vielleicht (entweder bist Du ein begnadeter Programmierer oder hast genügend Zeit), andere nicht.

Wir sollten uns darauf konzentrieren, etwas von der Stange zu nehmen.

Einige Messgerätehersteller (unsere Zulieferer) loggen ihr ganzes Zeugs in einer Access-DB (Singleuser) oder einem SQL-Server (Express). Wieso die Leute keine Open Source DB nehmen, weiss ich nicht.

Wenns ein Service ist, der exklusiv auf die Logdateien zugreift, würde ich zu einer Embedded-Version tendieren, wobei ich einen Kanal für SQL-Befehle jeglicher Art reservieren würde, um ggfs. mit einem DBAdmin-Tool Änderungen an den Rohdaten durchführen zu können.

[mkinzler]

Ab Firebird 2.5 kann man ja auch bei der embedded Varinate parallel auf eine Datenbank zugreifen.