Office: (Office 2013) Lösungsansatz Dateihandling in Bilddatenbank

Moin moin,

bei meiner Bilddatenbank hatte ich erst den Gedanken, alle Bilder in einem Ordner abzulegen und dort zu verwalten.
Aus diversen Gründen scheint mir das aber nun völliger Nonsens, insbesondere in Anbetracht der Unflexibilität.

Daher gedenke ich jetzt, mir meine Bildordner in ein Treeview einzulesen, so dass ich sie von dort aus ansteuern kann. Da aber auch nicht alle Bilder eines Ordners Aufnahme in die Bilddatenbank finden sollen überlege ich nun, wie ich das Ganze am besten handhaben kann.

Meine derzeitige Idee ist folgende:

Einlesen eines Ordners z.B. C:\Bilder samt Unterordnern und Bilddateien in das Treeview.
Beim Einlesen Abgleich mit der Bildtabelle, d.h. prüfen ob das jeweilige Bild in der Tabelle erfasst ist
Anzeige im Treeview je nach Option: Alle Bilder, erfasste, Nicht erfasste

Unabhängig vom Erfassungszustand wird jedes Bild nach Auswahl in einer Imagebox angezeigt.
Das Übernehmen in die Datenbank könnte mittels Button erfolgen.

Meine Frage ist nun, ob das eine brauchbare Lösung ist bzw. ob jemand einen anderen Lösungsvorschlag hat.

:)

 

Moin,
was hast du denn mit der Bilddatenbank vor und von wieviel Bildern reden wir hier? Wenn es dabei um das Archivieren und Wiederfinden von häufig verwendeten Bilddaten geht (Logos oder ähnliches) finde ich den Ansatz ganz ok, wenn du so deine 3500zig Urlaubsfotos verwalten willst, würde ich doch auf eine der zahllosen vorhandenen (Freeware-)Lösungen zurückgreifen.
maike

 

Hallo Maike,

es geht um Eisenbahnfotografie und die Infos zu den Bildern sind zu speziell, als das ich annehmen würde, das das eine Freewarelösung abdecken würde.
Beispielsweise soll zu einer Loknummer diverse Detaillinformationen abgespeichert werden. Gleiches gilt für die Fotostandorte u.a.

Wie viel Bilder es am Ende mal werden weiß ich nicht. Aber es geht sich nicht in die Tausende.

 

Ich mache etwas ähnliches für Dokumente. Dabei habe ich mich aber für ein Listenfeld entschieden, da es mir letztlich egal ist, wo die Dinger liegen, ob Ordner oder Unterordner ...
In der DB speichere ich dann den Pfad und die diversen Zusatzinformationen, nach denen sich dann auch suchen lässt.
maike

 

Mit dem Treeview hab ich natürlich etwas Explorerfeeling. Das ist mir schon wichtig und mit Unterordnern dürfte das schwer sein in einem Listenfeld.

Vllt. hat ja noch jemand eine Meinung zu meinem ANliegen.

Ich werde meine Idee mal weiterverfolgen. Mein Ansatz ergibt übrigens eine Dauer von 11 Sekunden um einen Bildordner mit 178 Unterordnern und 5207 Bildern in das Treeview zu lesen, inklusive Abgleich, ob Datei in der Tabelle existiert. Das ist natürlich Performancelastig aber man macht es ja auch nur einmal.

Edith: Die Nummer mit den 5.207 Bildern wäre aber auch nicht die übliche Arbeitsweise. Das ist ein Archiv und war eher zum testen.

 

Dies hängt uU davon ab wie es umgesetzt wurde, Dlookups auf jede einzelne Datei ist evtl. nicht wirklich der Hit, arbeiten mit Index und Seek sind ggf schneller, auch ist die Api FindFirstFile schneller als die Verwendung der FSO's aus dem Scriptdingens.
Auch könnte es schneller gehen, nicht alle Unterordner gleichzeitig einzu lesen, sondern nur beim Klick aufs Kreuzchen das entsprechende einzulesen.

 

http://www.acdsee.com/de/products/acdsee-17 momentan 35,00 Euro.
Für das Geld möchte ich das nicht selbst nachentwickeln *wink.gif*

Ansonsten klingt die Idee mit dem Treeview gut.
Um die Performance in den Griff zu bekommen finde ich den Ansatz von daolix gut; erst nur die Ordner in den Treeview laden und bei der Selektion des jeweiligen Ordners die Bilder "nachladen".

Evtl. reicht es aber auch schon, die Details in den Dateieigenschaften entsprechend zu pflegen (Stichwort EXIF, etc.)
Die Windowssuche sollte hier dann ggf. reichen um entsprechende Bilder der "Lok 0815 in Buxtehude" zu finden.

 

Danke für die Hinweise.

Das Programm macht einen guten Eindruck aber erfüllt auch nicht so wirklich meine Anforderungen und da ich mehr Zeit als Geld habe ist es für mich OK, mir das selbst zu entwickeln. Zudem schwebt mir vor, später eine angepasste Version als Access-App zu veröffentlichen.

• Das Treeview bei Nodeclick zu füllen erfordert aber auch dann noch einen Abgleich mit der Tabelle.
• Die Exiff's beim einlesen einzubeziehen, würde wahrscheinlich noch länger dauern als ein Abgleich mit der Tabelle, da die Exiffs ja auch erstmal ausgelesen werden müssen.
• Die weiter Oben erwähnte Nummer mit den 5.207 Bildern dauert ohne Tabellenabgleich die Hälfte der Zeit, also nur 6 Sekunden

Alternativ ist mir nun folgende Idee gekommen:

Bei jedem Bild, dass in der Datenbank erfasst wird, wird dem Bildnamen automatisch ein Präfix voran gestellt. Das sollte sich per Code leicht realisieren lassen.

Beim Einlesen in das Treeview wird keinerlei Abgleich gemacht. Unterschiede bei der Ausgabe im Treeview wären dann schon durch den Präfix ersichtlich und Formatierungen (bspw. Einschränkungen [erfasste/nicht erfasste] können von diesem abhängig gemacht werden.

Klickt man einen TreeviewItem an und die Date ist nicht erfasst, wird nur das Bild in die Vorschau geladen, der Datenbereich bleibt leer.

 

Hallo

Ein Suchen von 6050 Files in 407 Verzeichnissen mit Abgleich der Datensätze dauert hier mit Api, Index und Seek beim erstenmal 7,4 Sekunden(begrenzender Faktor ist hier das Einlesen der Festplatte), in gecachten Zustand 0,35 Sek. Also Access kann sehr flott vergleichen.

 

\@Daolix

kannst Du mir das mal schematisch näher bringen? Mir ist die Kombination der Teile momentan schleierhaft.

Die Variante mit dem Präfix ist womöglich nicht elegant. Aber wenn ich ohnehin alle Bilder zu Verfügung haben will, wozu dann einschränken.
Ein Präfix vor dem Dateinamen hätte IMHO auch den Vorteil, dass ich den Datenbankbezug erkenne, wenn ich mal mittels Explorer unterwegs bin.

 

Hallo

angenommen du hast eine Tabelle ähnlich folgendem erzeugt:
Code:

Diese Bsp-Tabelle besteht aus 3 Feldern ( f_FileIDf, _File, f_Path ) und 2 Indezes( Autowert, Fullpath). Fullpath ist ein index der hier über 2 Felder geht.
Jetzt öffnest du ( egal ob du nun Api, Dir, Dir oder FSo verwendest) vor dem Scan deiner Ordner ein Recordset vom Typ Tabelle Code:

und während des Scans vergleichst du ähnlich wie:
Code:

 

\@daolix
nun weiß ich, was Du gemeint hast. Ich habe dieses Prinzip auch schon ein paar mal angewandt. Ich werde das mal testen aber bevorzugen tue ich momentan meine Idee mit dem Präfix, weil ich dadurch gleich auch am Dateinamen erkenne, das ein Bild in der Datenbank ist.

 

Hab die Seek-Variante getestet. Sie ist genauso schnell (oder langsam) wie wenn ich nur den Präfix prüfe. Ich werde sie dann auch beibehalten. Letztlich ist mir doch aufgegangen, dass es die sichere Methode ist um zu prüfen, ob eine Bilddatei in der Datenbank erfasst ist.

Nur mit dem Präfix müsste ich dann auch beim Löschen eines Bilddatensatzes immer den Präfix entfernen.

Frage:
Meine Bildtabelle hat derzeit 17 Spalten. Die werden ja durch 'Openrecordset' alle geladen. Ist damit zu rechnen, dass weniger Spalten mehr Geschwindigkeit bringen?

 

Um das Thema abzuschließen poste ich hier mal meinen Code zum Einlesen von Ordnern in ein Treeview. Der Code liegt in einem Modul namens 'trv', welches auch im Anhang als *.bas zu finden ist.

In meiner Anwendung habe ich eine Imagelist mit 3 Bildern, deren Bilder den Nodes zugewiesen werden. Für die Dateien habe ich dabei Symbole mit rotem (nicht erfasste Dateien) oder grünem (erfasste Dateien) Hintergrund. Wer den Code testen will braucht entweder eine Imagelist oder muss die entsprechenden Codezeilen demarkieren und die Auswertung entsprechend anpassen.

Der Aufruf kann so aussehen:
Code:

Es wird das Treeview ByRef übergeben, dann der Pfad zu dem Ordner. Der dritte Parameter [Optional] ist bei mir eine Optionsgruppe, die festlegt, ob alle Bilder, in der DB erfasste oder nicht erfasste Bilder einlesen soll. Wird er weg gelassen, werden alle Bilder eingelesen.

Vielen Dank für Eure Hilfe und schönes Wochenende *Smilie

Code:

 

Tendenziell bis praktisch JA.

Das Recordset landet zur Verarbeitung im Arbeitsspeicher Deines Rechners. Da muss es Platz finden. Wenn nun erst dafür Speicher freigeräumt werden muss durch Auslagerung anderer Daten in die Auslagerungsdatei, müssen da I/O-Aktionen auf die Festplatte erfolgen, und diese Vorgänge sind deutlich langsamer als Aktionen direkt im RAM. Noch etwas dramatischer ist es, wenn das Recordset selber nicht in den verfügbaren Arbeitsspeicher passt.

Dazu kommen dann Effekte, die mit dem Holen der Daten zusammenhängen, etwa
- der Netzwerktraffic,
- dass Jet alle Datensätze statt nur gefilterte Datensätze holt
u.a.

Ein möglichst schlankes Recordset ist also stets angeraten.