Speicherbedarf von Access-DB sehr groß

[jobo]

@Versuche 1+2
Ich finde den Gedanken von Bernhard trotzdem gut.
Nur wenn sichergestellt ist, dass der Zielfeldtyp binär ist und kein Textformat, dann wäre es widerlegt. (Vorausgesetzt beim Füllen der Felder passiert keine implizite Umwandlung, bevor es binär gespeichert wird)

Deine Gründe kann ich nachvollziehen. Daher wäre es evtl. eine Alternative, nur die Links auf die Dateien im Filesystem zu speichern. Dann muss aber garantiert sein, dass niemand außer dem Programm drin rumpfuscht.

Konntest Du schon was zum Thema Blockgröße finden?
Ein anderer Test wäre das (einmalige) Speichern einer sehr großen Datei, MB Bereich oder sowas, kann man vielleicht besser prüfen.

Noch eine Idee wäre eine Komprimierung der mdb nach dem Import...

[Perlsau]

Zitat von KPBecker:

@Perlsau:
Access ist für mich am einfachsten da vorhanden
MySQL wäre auch noch möglich

Firebird ist, da kostenlos im Netz verfügbar, quasi auch vorhanden. Du mußt bei einem Kunden kein Firebird installieren, wenn du die Embedded-Version mitgibst, das ist einfach ein paar DLLs (u.a. fbclient.dll), die im Programmverzeichnis liegen. Der Vorteil gegenüber Access ist gewaltig! Schon allein bei Blob-Feldern: speicherst du in Access z.B. JPG-Grafiken ab, fügt Access dem Pic eigensinnig noch ein paar Byte hinzu, die du beim Auslesen mühevoll wieder wegschneiden mußt. Ansonsten gibt es bei Access nichts, was es nicht auch in Firebird gibt. Für MySQL gibt es meines Wissens nach dagegen keine Embedded-Version.

Zitat von KPBecker:

Der Gedanke, daß in einem Memo 2-Byte-Zeichen in der DB abgelegt werden und daher der Faktor >2 in den Größen (Dateien vs. DB) liegt, stimmt möglicherweise nicht.
Versuche:
1. Textfeld als Memo bzw. als OLE (BLOB) definiert, schreiben des Inhalts als Stringlist mit Text.CommaText
--> kein Unterschied in der DB-Größe
2. Umsetzen von Text.CommaText in einen Ansi-String, der dann wie bei 1. in ein Memo bzw. OLE-Feld abgelegt wird
--> kein Unterschied in der DB-Größe

Die Größe einer Datenbank kann vor und nach dem Einfügen von Daten gleich sein, du siehst die Größenänderung erst nach einer erneuten Kompilation (bei Access: nach Komprimierung, bei Firebird: nach BackUp & Restore).

[Bernhard Geyer]

Zitat von Perlsau:

Der Vorteil gegenüber Access ist gewaltig! Schon allein bei Blob-Feldern: speicherst du in Access z.B. JPG-Grafiken ab, fügt Access dem Pic eigensinnig noch ein paar Byte hinzu, die du beim Auslesen mühevoll wieder wegschneiden mußt.

Aber nur wenn du es mit der Access-Oberfläche machst. Über ADO nicht.

Zitat von Perlsau:

Für MySQL gibt es meines Wissens nach dagegen keine Embedded-Version.

Gibt es. Jedoch hat man bei MySQL die GPL-Falle. Entweder OpenSource oder pro Jahr bis zu 20-30k€ Lizenzkosten für eine unbegrenzte Verteilung. Ansonsten für nicht OpenSource pro Verteilung ein MySQL Serverlizenz.


Um zu sehen wie es gespeichert wird: Einfach Hex-Editor nehmen und nach dem Text der Textdatei suchen. Dann sieht man genau wie es im MEMO/Varchar bzw. im Blob-Feld abgespeichert wird. Oder einfach mal 100.000 mal gleichen Text speichern um ungenauigkeiten von "Blockgrößen-Anforderungen" zu vermeiden.

[franktron]

Zitat von Bernhard Geyer:

Zitat von Perlsau:

Für MySQL gibt es meines Wissens nach dagegen keine Embedded-Version.

Gibt es. Jedoch hat man bei MySQL die GPL-Falle. Entweder OpenSource oder pro Jahr bis zu 20-30k€ Lizenzkosten für eine unbegrenzte Verteilung. Ansonsten für nicht OpenSource pro Verteilung ein MySQL Serverlizenz.


Um zu sehen wie es gespeichert wird: Einfach Hex-Editor nehmen und nach dem Text der Textdatei suchen. Dann sieht man genau wie es im MEMO/Varchar bzw. im Blob-Feld abgespeichert wird. Oder einfach mal 100.000 mal gleichen Text speichern um ungenauigkeiten von "Blockgrößen-Anforderungen" zu vermeiden.

Dann nimmt man MariaDB ist ein MySQL Fork und ist komplett GPL V2

[mkinzler]

MySQL ist auch unter GPL verfügbar. Diese verlangt aber dass man sein Programm dann auch unter diser veröffentlicht.

[p80286]

Zitat von KPBecker;1099845@schorsch666 & p80286:

Das Ziel war, die Information "übersichtlicher" als in großen Verzeichnissen abzulegen, schnelleren Zugriff auf den Inhalt einzelner Dateien zu haben, die Bearbeitung nach Datum vornehmen zu können und im Datensatz einfach ein "Verarbeitungskennzeichen" mitzuführen. Daher auch die Indizes auf diesen Angaben. Außerdem wollte ich Verschnitt durch die Blockung bei Dateien vermeiden (haha).
Tips sind natürlich immer willkommen.

Wenn Du unbedingt Platz sparen willst, und der direkte Zugriff für den Benutzer nicht gegeben sein muß, alle in Dateinen in einer Datei (pro Tag, pro Monat, pro irgendwas zusammen fassen).
Wenn Du jede Datei mit einem Kenner am Anfabg versiehst, und das Abspeichern auch noch mit brachbaren Blockgrößen erfolgt (Platz sparen??) solltest Du auch schnell zugreifen können.
Nur ist das schon beinahe das Nachbauen einer Datenbank.....

Gruß
K-H