BVA-System

Der erste Monat des Jahres ist schon wieder um und es ist wieder einmal Zeit, eine neue Programmversion zu veröffentlichen. In den letzten Wochen habe ich 2 größere Baustellen bearbeitet.

Bisher war es inkonsequent, das eine einzige Bearbeitungsfunktion, das Erstellen von einem Fotoindex, nicht über den Worker ausgeführt wurde. Außerdem hatte die alte Funktion einen richtig fiesen Fehler. Wenn nämlich nicht alle Thumbnails der Bildliste fertig geladen gewesen sind, als der Index erstellt werden sollte, so gab es auf dem Fotoindex lauter leere Kästchen. Es lag also nahe, die Funktion so umzubauen, das sie nun auch über den Worker ausgeführt wird. Und da ich da schon einmal bei gewesen bin, habe ich der Fotoindex-Funktion auch gleich einen hübschen Einstellungsdialog spendiert.

Einstellungsdialog für den Fotoindex

Die zweite Baustelle war das Löschen von Bildern aus der Datenbank. Bisher war es so, das nach dem Löschen unter Umständen leere Einträge im Aufnahmedatumbaum stehen geblieben sind. Jetzt werden diese Einträge gelöscht. Aufwendig war dieser Punkt, da die vom Worker gelöschten Rubriken auch in der Oberfläche gelöscht werden mussten.

Mit der nächsten Version wird es wieder eine Datenbankstrukturänderung geben. Ich werde nämlich damit beginnen, eine Fotoalbumfunktion in das Programm zu integrieren. Es soll die Möglichkeit geschaffen werden, das der Anwender Fotoalben in der Datenbank anlegen kann. Jedes Album soll wiederrum Unteralben enthalten dürfen. Die in der Datenbank importierten Bilder sollen einem oder mehreren Alben zugewiesen werden können. Ziel ist es, das eine strukturierte Ansicht entsteht, in der man einfacher navigieren kann als im Aufnahmedatumbaum. Es ist beispielsweise einfacher, die Rubrik „Geburtstagsfeiern“ und die Unterrubrik „Tante Trude 2008“ auszuwählen, als die Geburtstagsbilder von Tante Trude im Aufnahmedatumbaum zu finden.

Ich schätze, das die Fotoalbumfunktionen für eine einzelne Version zu umfangreich sein wird. Daher steht nicht nur die nächste, sondern mindestens die nächsten 3 Versionen im Zeichen der Fotoalben.

Als die Version 1.0 des BVASystems damals das Licht der Welt gerade erblickt hatte, meldete sich ein Kunde bei mir mit dem Wunsch, das im Netzwerkbetrieb nicht jeder Nutzer Zugriff auf alle Bilddaten haben soll. Damals entschied ich mich dazu, dem nicht weiter nachzugehen, da die Datenbankstruktur zu verbaut gewesen ist, um auf einfachem Weg eine Nutzerverwaltung  in das Programm zu integrieren.

Ob im neuen BVASystem eine Nutzerverwaltung gebraucht wird, kann ich aktuell nicht richtig entscheiden. Auf der einen Seite ist es sicherlich sinnvoll, wenn Nutzer A die Bilder von Nutzer B nur sieht, wenn Nutzer B dies will und Nutzer A sie auch sehen möchte. Auf der anderen Seite scheue ich aber dem Aufwand, der in der Implementierung einer Nutzerverwaltung liegt. Ich denke, das es aktuell weit wichtigere Features gibt, die auf ihre Umsetzung warten. Da wäre zum Beispiel die Zuordnung der Bilder zu Fotoalben, die als nächstes auf der Roadmap ansteht.

Entschieden habe ich mich aktuell für ein Aufschieben der Entscheidung, aber verbauen möchte ich mir diesmal die Möglichkeit zur Nutzerverwaltung nicht. Ich habe mir überlegt, das ich die Zugriffsverwaltung des Datenbanksystems auch für die Nutzerverwaltung im BVASystem nutzen könnte. Für jeden Nutzer muss dafür ein Account auf dem Datenbanksystem erstellt werden, welcher Zugriffsrechte auf die BVASystem-Datenbank erhält. Diese Accounts lassen sich dann dazu nutzen, die verschiedenen Nutzer zu unterscheiden.

Mit der letzten Datenbankänderung hat sich eine kleine Tabelle in die Datenbankstruktur geschlichen. Dort wird ab der nächsten Version, die sicherlich in den nächsten Tagen fertig werden wird, der Nutzername gespeichert, der sich an der Datenbank angemeldet hat. Fügt der Nutzer Bilder zur Datenbank hinzu, wird sein Nutzername mit den Bildern verknüpft. Somit wäre der erste Schritt zur Nutzerverwaltung getan. Die Datenbank weiß, wem welches Bild gehört.

Weitere Konsequenzen hat die Speicherung des Nutzernamens aber nicht und es ist für die nächsten Versionen auch nicht geplant, daran etwas zu ändern. Aber, wer die Bildverwaltung mit mehreren Nutzern einsetzen möchte, dem sei jetzt bereits angeraten, für jeden Nutzer einen Datenbank-Account anzulegen.

Die 14 Tage sind nun schon wieder um und es ist an der Zeit, das BVASystem zu aktualisieren. Die meiste Zeit der letzten 14 Tage habe ich damit verbracht, das Herstellen der Datenbankverbindung zu überarbeiten. Bisher war es so, das alle nötigen Verbindungsparameter in der Ini-Datei eingegeben werden mussten. Außerdem war es nicht möglich, eine einmal hergestellte Datenbankverbindung zu trennen und beim erneuten Verbindungsversuch stürzte das Programm einfach ab.

Dies ist nun alles anders. Die 4 Parameter Serveradresse, Datenbank, Nutzer und Passwort müssen nun nicht mehr zwingend in der Ini-Datei stehen. Beim Herstellen der Datenbankverbindung wird nun ein Login-Dialog angezeigt. Dort sind die Datenfelder mit den Daten aus der Ini-Datei vorbelegt. Fehlende Daten können vom Nutzer nachgetragen werden. Auch das Trennen der Datenbankverbindung ist nun möglich und anschließend kann auch eine neue Datenbankverbindung hergestellt werden.

Logindialog der Bilddatenbank

Außerdem habe ich noch einige kleinere neue Features in das Programm integriert. Zum Beispiel können die Bildlisten nun nach Name sortiert werden. Die genaue Änderungsliste findet ihr hier: Änderungsliste

Heute möchte ich mich mit der Frage beschäftigen, wo eine Bildverwaltungssoftware die Bilddaten abspeichert. Prinzipiell gibt es 2 Möglichkeiten: die Bilder können mit den Metadaten zusammen in der Datenbank gespeichert werden. oder es kann in der Datenbank nur eine Referenz, bestehend aus Pfad+Dateiname des Bildes, abgelegt werden. Beide Methoden haben ihre Vorteile, aber auch Nachteile.  Da keine der Methoden frei von Nachteilen ist, kann man sich darüber streiten, welche Methode nun die bessere ist. Schlussendlich ist es also eine Entscheidung des Anwenders, welche Methode er bevorzugt.

Bevor ich auf die Vor- und Nachteile eingehe, möchte ich kurz schildern, welches Konzept das neue BVASystem verfolgt bzw. verfolgen wird. Es werden im BVASystem pro Datensatz 3 Bilder abgespeichert. Als erstes wäre da das Thumbnail, welches in der Bildliste angezeigt wird. Standardmäßig hat das Thumbnail eine maximale Bildhöhe von 200 Pixel. Weiterhin wird ein Vorschaubild gespeichert, welches angezeigt wird, wenn der Anwender das Bild im angepassten Zoommodus betrachtet. Es hat standardmäßig eine maximale Höhe von 800 Bildpunkten und lässt sich damit auch auf älteren Rechnern schnell laden und anzeigen. Sowohl das Thumbnail, als auch das Vorschaubild werden in der Datenbank gespeichert. Als drittes wird natürlich die Originalbilddatei gespeichert, welche angezeigt werden soll, sobald der Anwender den angepassten Zoommodus verlässt. Aktuell ist es so, das auch das Originalbild in der Datenbank abgelegt wird. Die Datenbankstruktur ist aber so angelegt, das anstelle des Bildes auch eine Referenz gespeichert werden kann. Der Anwender soll sich später  einmal in den Optionen aussuchen können, ob das Originalbild in der Datenbank oder als Referenz gespeichert werden soll.

Ich habe mich zu diesem Konzept entschieden, da ich mit dem Programm meine eigenen Bilder im Heimnetzwerk verwalte. Da ist es einfacher, wenn die Bilder zentral auf dem Server gespeichert werden, damit alle Rechner darauf zugreifen können. Durch meine kurze Begründung für das Konzept bin ich nun aber auch schon mittendrin bei den Vor- und Nachteilen der beiden Möglichkeiten.

Speicherung der Bilder in der Datenbank

Für die Speicherung der Bilder in der Datenbank spricht, das das Programm damit komplett netzwerkfähig wird. Es macht keinen Unterschied, ob der Datenbankserver lokal, im Heimnetzwerk oder gar im Internet liegt. Es kann immer auf die gleiche Art und Weise auf die Bilder zugegriffen werden. Ebenfalls vorteilhaft ist, das die eingestellten Daten zentral an einer Stelle gespeichert sind. Dadurch können die Daten leicht gesichert und bei einem Datenverlust auch leicht wiederhergestellt werden. Als dritter Vorteil fällt mir ein, das man das Berechtigungssystem der Datenbank nutzen kann, um unerlaubten Zugriff auf die Bilddaten zu verhindern. Bei einer lokalen Installation wird man dies wohl nicht benötigen, aber im Netzwerkbetrieb mit mehreren Nutzern kann dies schon von Bedeutung sein.

Nachteilig an der Speicherung der Bilder in der Datenbank ist, das die Bilder erst wieder  exportiert werden müssen, wenn man sie außerhalb der Bildverwaltung benötigt. Will man die Bilder beispielsweise an ein Fotolabor senden, so wird dies nicht auf direktem Wege funktionieren. Zuerst müssen die ausgewählten Bilder in ein temporäres Verzeichnis auf der Festplatte kopiert werden. Von dort können sie dann ans Fotolabor gesendet werden. Einige sehen dies aber auch als Vorteil, den die Originalbilddateien sind in der Datenbank dadurch sicher vor ungewollten Änderungen. Es geht ganz schnell, das man beispielsweise beim Drehen eines Bildes mit einem Bildbearbeitungsprogramm plötzlich den EXIF-Header des Bildes, der die Meta-Daten wie Aufnahmedatum oder Aufnahmeort enthält, verliert.

Von der Performance her ist die Speicherung der Bilddaten in der Datenbank langsamer als auf dem Dateisystem. Dies erklärt sich dadurch, das kein direkter Zugriff vom Programm auf die Bilddatei erfolgt. Der Zugriff erfolgt zweistufig: Das Programm stellt eine Anfrage an die Datenbank und diese liest dann die Bilddatei von der Festplatte. Häufig angezeigte Bilder wird die Datenbank im Arbeitsspeicher cachen und damit schneller ausliefern als das Dateisystem.

Als größten Nachteil für die Datenbankspeicherung sehe ich die starke Abhängigkeit von der Verwaltungssoftware. Wenn die Software von heut auf morgen nicht mehr weiterentwickelt wird, hat der Anwender ein Problem. Neuer Rechner, neues Betriebssystem und schon nützt einem nichtmal mehr ein Datenbackup, weil die alte Software einfach nicht mehr läuft. Man kann zwar mit Hilfe von Tools der Datenbankhersteller ebenfalls auf die Datenbank zugreifen, aber dafür benötigt man schon einiges an Fachwissen. Außerdem ist die Art von Datenzugriff nicht wirklich komfortabel.

Speicherung von Bildreferenzen

Bei der Speicherung von Bildreferenzen ist die Sache genau anders herum. Der Anwender behält weiterhin vollen Zugriff auf seine Bilder. Die mit der Verwaltungssoftware erstellten Bildbeschreibungen, speichert das Programm idealerweise direkt im Bild ab. Sollte die Software nicht mehr weiterentwickelt werden, oder der Anwender hat ein besseres Programm gefunden, so importiert er seine Bilder einfach mit samt den Bildbeschreibungen in das neue Programm. Auch kann der Anwender sofort auf seine Bilddaten zugreifen, wenn er sie an ein Fotolabor schicken möchte.

Der einfache Zugriff auf die Bilder ist aber auch der größte Nachteil der Bildreferenzen. Der Anwender kann zu jeder Zeit Bilder löschen, verschieben oder umbenennen. In der Datenbank der Verwaltungssoftware entstehen dadurch Datensätze, die keinem Bild mehr zugeordnet werden können. Im schlimsten Fall ist der Sinn der Verwaltungssoftware verfehlt, da der Anwender sein gesuchtes Bild nicht wiederfindet, weil er es vor ein paar Monaten in ein anderes Verzeichnis verschoben hat ohne dabei an die Bildverwaltung zu denken.

Eine Netzwerkfähigkeit ist mit Bildreferenzen nur bedingt erreichbar. Im lokalen Netzwerk kann man vielleicht noch mit Netzwerklaufwerken arbeiten um einen Zugriff von mehreren Rechnern aus zu gewährleisten. An der Stelle wird es aber bereits schwierig, ungewünschte Zugriffe auf die Bilder zu verbieten.

Fazit

Wie bereits oben gesagt, war für mich die Netzwerkfähigkeit der ausschlaggebende Punkt mich für die Speicherung der Bilder in der Datenbank zu entscheiden. Wie sieht es bei euch aus? Speichert ihr die Bilder in der Datenbank oder nutzt ihr nur Bildreferenzen?

Das neue Jahr ist noch keine Woche alt und schon gibt es das erste Update für das BVASystem. Die größte Änderung, die in der neuen Version auffallen dürfte, ist es, das Bilder nun in 90 Grad Schritten gedreht werden können. Für den Bildbetrachter ist dies ein ganz nettes Feature, aber so richtig interessant wird es erst, wenn die Bilder in der Datenbank sind.

Screenshot des BVASystems 2.0.0.14

Folgender Fall: Ich habe mit einer Digitalkamera ein Portrait im Hochformat aufgenommen, welches natürlich am Rechner immer um 90 Grad verdreht dargestellt wird. Importiere ich nun dieses Bild, ohne es vorher zu bearbeiten, in die Datenbank und drehe es anschließend richtig, wird automatisch eine Worker Aufgabe erstellt. Durch diese Aufgabe wird der neue Orientierungssinn des Bildes abgespeichert. Betrachte ich zu einem späteren Zeitpunkt das Bild erneut, wird es gleich richtig herum angezeigt. In der Datenbank ist das Bild aber immernoch so gespeichert, wie es aufgenommen wurde.

Die zweite große Änderung betrifft den Baum mit den Aufnahmedaten. Ich habe es nun umgesetzt, das neue Aufnahmedaten sofort nach dem Datenimport in den Baum eingetragen werden. Das nervige auf und zuklappen des Baumes zur Aktualisierung entfällt damit absofort.

Achtung: Damit das neue Program weiterhin funktioniert, ist es notwendig die Datenbank zu aktualisieren. Die alte Datenbankstruktur hat nicht mehr ausgereicht, um die beschriebenen Funktionen umzusetzen. Die aktualisierte MySQL Workbench Projektdatei befindet sich nach der Installation im Unterverzeichnis „DB“. Da ich größere Änderungen an der Datenbankstruktur vorgenommen habe, empfehle ich die Datenbank per „Forward Engineer..“ zu aktualisieren. Damit gehen zwar die bestehenden Daten verloren, aber so dürften bei der Erzeugung der Datenbankstruktur keine Fehler auftreten.

Für die nächste Version habe ich mir vorgenommen, die Funktionen zum Herstellen der Datenbankverbindung bzw. zum Trennen der Verbindung zu überarbeiten. Aktuell ist es so, das beim Trennen der Datenbankverbindung gar nichts ausgeführt wird. Beim erneuten Verbindungsversuch stürzt das Programm dann leider ab. Außerdem wäre es schön, das man mindestens das Passwort nicht fest in der Konfigurationsdatei eingeben muss. Dafür werde ich mir eine Lösung überlegen.

Die letzten Stunden des Jahres sind angebrochen und ich möchte diese dafür nutzen, ein Fazit ziehen.  Es ist Zeit, sich einmal damit auseinander zu setzen, was in den vergangenen Monaten erreicht wurde. Und natürlich müssen die „Vorsätze“ fürs neue Jahr aufgeschrieben werden, damit nächstes Jahr dann wieder eine Bilanz gezogen werden kann.

Der Plan, ein neues BVASystem zu programmieren, ist mittlerweile 3 oder sogar schon 4 Jahre alt. Das Abenteuer Hausbau verhinderte bisher allerdings, das ich abends die Motivation dazu hatte, mich vor den Rechner zu setzen. Dieses Jahr zu Ostern konnte ich die letzte große Baustelle auf meinem Grundstück abschließen. Nachdem der Muskelkater verzogen war, suchte ich wieder nach neuen Herausforderungen und fand diese im BVASystem 2.0.

Die erste Ankündigung für das neue BVASystem mit Datenbank stammt vom 21. Juli 2010, ich habe also nur ein halbes Jahr damit verbracht, an dem Programm zu schrauben.  Prinzipell bin ich mit dem Entwicklungsstand, der erreicht wurde, sehr zufrieden. Es ist nur ein klein wenig deprimierend,  das man in einem Hobbyprojekt weit mehr Ideen hat, als man in der wenigen Zeit umsetzen kann. Aber einen der Hauptkritikpunkte des alten BVASystems, das langsame, träge Laden der Bilder,  konnte ich mehr als beseitigen. BVASystem 2.0 ist zu einem sehr guten, schnellen Bildbetrachter geworden. Es gibt quasi keinen Tag an dem ich es nicht verwende.

Datenbanktechnisch bin ich nicht ganz so weit gekommen, das es sich lohnen würde das Programm zur Verwaltung seiner Bilder einzusetzen. Es wurde nur geschafft, den Import von Bildern in die Datenbank zu implementieren. Dies aber auf einer Art und Weise, die viel komfortabler ist als im alten Programm. Und durch den Worker wurde ein System geschaffen, mit dem Änderungen am Datenbestand fast unsichtbar für den Anwender durchgeführt werden können.

Die erste Version, die im neuen Jahr veröffentlich wird, wird eine Worker-Funktion beinhalten, die den Orientierungssinn von Datenbankbildern speichert. Wird ein Datenbankbild gedreht, so wird automatisch gleichzeitig ein Workertask erstellt. Soll das Bild dann später wieder angezeigt werden, so wird es gleich wieder gedreht. Natürlich ohne das an der Bilddatei etwas geändert wird.

Für das neue Jahr habe ich mir vorgenommen, weiterhin mit dem bestehenden System weiterzuentwickeln. Ich möchte ungefähr alle 2 bis 3 Wochen eine neue Version hier auf die Homepage stellen. Schwerpunkttechnisch wird die Entwicklung stärker in Richtung Datenbank gehen, da dort ja noch weit mehr fehlt als beim Bildbetrachtermodul. Aber auch der Bildbetrachter wird die eine oder andere Verbesserung erfahen, da mir durch den täglichen Einsatz sicher noch ein paar Ideen kommen werden. Die genaue Roadmap für die nächsten 2-3 Versionen werde ich in den nächsten Tagen in den Bugtracker eintragen. Lasst euch also ein klein wenig überraschen, was in den nächsten Versionen kommen wird.

In diesem Sinne, kommt gut ins neue Jahr und ich hoffe auf ein Wiedersehen spätestens beim nächsten Programmupdate.

Im letzten Blog hatte ich es ja bereits angedeutet, in der ab heute zum Download bereitstehenden Programmversion, ist ein komplett überarbeitetes Hauptmenü enthalten. Nicht verraten hatte ich aber, wie mein Konzept für das neue Menü aussieht. Dies hole ich nun aber nach:

Das neue Hauptmenü ist in 4 Hauptrubriken eingeteilt, da sich die Oberfläche ebenfalls in 4 eigentständige Teile trennen kann: die Hauptwerkzeugleiste, den Verzeichnis- bzw. Rubrikenbaum, das Vorschaubild und die Bildliste. Hinter dem Menüeintrag „Programm“ verbergen sich alle Funktionen, die in der Hauptwerkzeugleiste zu finden sind. Im Menüeintrag „Baum“ befinden sich alle Funktionen, die sich durch ein PopUp-Menü im Verzeichnis- bzw. Rubrikenbaum erreichen lassen. Der Menüeintrag „Vorschaubild“ enthält alle Funktionen, die sich ebenfalls in der Werkzeugleiste unter dem Vorschaubild befinden. Und zu guter letzt sind im Menüeintrag „Bildliste“ alle Funktionen verfügbar, die durch das PopUp-Menü der Bildliste ausgeführt werden können.

Das neue Hauptmenü

Außer dem neuen Hauptmenü haben es noch ein paar weitere Veränderungen ins Programm geschafft. Als erstes sollte sicher Auffallen, das es den „Test Connect DB“ Button nicht mehr gibt. Ersetzt wurde er durch ein per Ini-Datei konfiguierbares AutoConnect. Fügt man in der BVASystem.ini unter [DATENBANK] die Zeile AUTOCONNCECT=JA ein, so wird die Datenbankverbindung automatisch beim Programmstart hergestellt. Ist eine automatische Datenbankverbindung nicht erwünscht, so kann sie natürlich auch, während das Programm läuft, hergestellt werden. Die dazugehörigen Buttons in der Hauptwerkzeugleiste werden sicher auch ohne große Erklärungen eindeutig sein.

Auch in der nächsten Version werde ich hauptsächlich Änderungen an der Programmoberfläche vornehmen. Geplant ist, das verdrehte Bilder in 90 Grad Schritten gerade gerückt werden können. Außerdem möchte ich dafür sorgen, das wenn neue Bilder in die Datenbank aufgenommen wurden, der Rubrikenbaum automatisch aktualisiert wird.

Die letzte Nacht habe ich damit verbracht, die Buttons der Funktionsleiste unter dem Vorschaubild umzustellen. Als ich vor einem Jahr begonnen habe, das neue BVASystem zu entwickeln, war die Funktionsleiste so ziemlich das erste was ich implementierte. Ich entschied mich dafür, die Toolbar in einer eigenen Komponente, der TImgViewToolbar, zu kapseln. Für die einzelnen Funktionen der Knöpfe erstellte ich Ereignisse, die ich in der Hauptanwendung implementierte. Die Steuerung über den Status der Buttons übernahm die Komponente, war nach außen hin also nicht sichtbar.

Anfang der Woche stolperte ich, dann aber beim Neugestalten des Hauptmenüs auf ein Problem. Auch im Hauptmenü müssen die einzelnen Funktionen wie in der Funktionsleiste aktiviert bzw. deaktiviert werden. Einfachste Lösung wäre sicher gewesen, die Funktion aus der TImgViewToolbar zu kopieren und ebenfalls für das Hauptmenü zu verwenden. Da ich aber Wert darauf lege, sauberen Programmcode zu schreiben, war diese Lösung für mich sofort unten durch.

Meine Wahl fiel schlussendlich dann darauf, die Funktionen über den TActions-Konstrukt zu implementieren.  In der Hauptanwendung habe ich einen TActionsmanager hinzugefügt. Dort kann man recht einfach, über einen kleinen Dialog, Aktionen definieren. Diese Aktionen können dann mit einer Reihe von Standardkomponenten verknüpft werden. Zum Beispiel können ganz leicht Menüs oder Toolbars mit den Aktionen verbunden werden. Die Funktion, die ausgeführt werden soll, wenn die Aktion aufgerufen wird, packt man einfach in das OnExecute()-Event:

procedure TfrmMain.AcImgVollbildExecute(Sender: TObject);
begin
 if g_AktQuery <> nil then begin
  if g_AktQuery.DataList <> nil then begin
   if g_AktQuery.DataList.Count > 0 then begin
    frmVollBild.Show;
   end;
  end;
 end;
end;

Der Vorteil des ganzen ist nun, wenn man eine Funktion deaktieren will, weil sie gerade nicht sinnvoll ausgeführt werden kann, so braucht man diese nur auf inaktiv zu schalten. Alle Dialogelemente, die mit der Aktion verknüpft wurden, sind dann ebenfalls deaktiviert.  Weitere Vorteile sind, das auch Hints, Bilder und Beschriftungen nur einmal zentral bei den Aktionen definiert werden müssen. Nachteil ist für mich jetzt nur, das ich die gute alte TImgViewToolbar auf TActions umstellen musste, was natürlich Arbeit bedeutete.

Diese habe ich gestern abend aber doch recht schnell erledigen können. Aus den alten Events der Komponente sind nun Eigenschaften vom Typ TAction geworden. Intern, in der Komponente, werden die Aktionen nur noch den einzelnen Knöpfen zugeordnet. Und das schöne ist, die Komponente kann sich weiterhin darum kümmern, das die Buttons aktiviert bzw. deaktiviert werden. Sie bekommt aber gar nicht mit, das dabei das Hauptmenü gleich mit aktiviert bzw. deaktiviert wird.

In dem diesmaligen Entwicklungszyklus habe ich es geschafft, meinen alten Rekord von 12 abgearbeiteten Tickets in einer neuen Version zu brechen. Ganze 16 Punkte habe ich in den rund 2 Wochen geschafft. Ok, viele der Tickets hatten diesmal nicht so einen großen Umfang, aber der Teufel steckte oft in den Details. So war zum Beispiel die Überarbeitung des Popupmenüs der Bildliste etwas tricky. Je nachdem ob kein Bild, ein Bild oder mehrere Bilder markiert sind und ob das aktive Bild markiert ist oder nicht, werden unterschiedliche Beschriftungen im Popupmenü angezeigt.

Die größte Änderung, die ich hier extra erwähnen will, ist der Fingerprint. Wenn ein Bild in der Datenbank abgespeichert wird, so wird mit dem Bild eine Art Fingerabdruck erzeugt und mitgespeichert. Versucht der Anwender das Bild nun ein zweites Mal in der Datenbank abzulegen, so wird dies, aufgrund des bereits in der Datenbank vorhandenen Fingerprints, verhindert. Selbst wenn das Bild in der Zwischenzeit umbenannt wurde, wird trotzdem erkannt, das es sich um ein doppeltes Bild handelt.

Hauptdialog der Version 2.0.0.11

Die Details zu den Änderungen können, wie immer, im Bugtracker nachgeschlagen werden. Da der letzte Screenshot nun auch schon etwas älter war, habe ich heute einen neuen erstellt. Und zu guter Letzt habe ich heute noch, ebenfalls im Bugtracker, abgesteckt wohin die nächsten beiden BVASystem Versionen führen werden.

In der nächsten Version der Bilddatenbank möchte ich mich darum kümmern, das die Verbindung zur Datenbank nicht mehr über den Testbutton hergestellt werden muss.  Außerdem möchte ich die Möglichkeit schaffen, das das Programm als reiner Bildbetrachter nutzbar wird. Dabei soll, auch ohne Datenbankserver, der Anwender nicht von Fehlermeldungen genervt werden. In der übernächsten Version muss dann die Datenbankstruktur erweitert bzw. überarbeitet werden, damit Platz für neue Features ist. Im speziellen ist angedacht, das falsch ausgerichtete Bilder gedreht werden können und das der Orientierungssinn auch gespeichert wird.

Heute möchte ich die Gelegenheit nutzen, um die Frage zu beantworten, warum ich beim BVASystem auf ein Client-Server-Datenbankmodell gesetzt habe. Bevor ich jetzt aber groß in die Vor- und Nachteile einer Client-Server-Architektur einsteige, möchte ich kurz erklären, was das eigentlich ist.

Was ist ein Client-Server-System?

Wie der Name es sagt, besteht ein Client-Server-System aus 2 Komponenten, dem Client und dem Server. Bei beiden handelt es sich um eigenständige Programme, die in der Regel auf unterschiedlichen Rechnern in einem Netzwerk laufen. Es ist aber auch möglich, das Server und Client auf nur einem Rechner laufen. Der Server hat in der Regel keine eigene Oberfläche. Seine Aufgabe ist es, dem Client bestimmte Funktionen zur Verfügung zu stellen. Der Client ist das Programm, welches der Anwender gut kennen sollte. Der Client nutzt die Funktionen, die der Server zur Verfügung stellt und zeigt die Resultate dieser Funktionen dem Anwender an.

Beim BVASystem ist der Server ein Datenbankmanagementsystem, wie zum Beispiel das während der Entwicklung genutzte  MySQL.  Der Server hat hier die Aufgabe, die Fotos, die der Client dem Server übermittelt, zu speichern und zu einem späteren Zeitpunkt dem Nutzer wieder anzuzeigen. Eigentlich sollte es jetzt bereits klar sein, der Client ist in dem System das Programm, welches ich gerade programmiere.

Welche Vorteile und Nachteile hat ein Client-Server-System?

Für mich ist der größte Vorteil, das ich meine Fotos nur auf einem Server speichern muss. Ich bin im Besitz von mehreren Computern, die ich hier in einem Heimnetzwerk miteinander verbunden habe. Zum einen habe ich einen Standrechner, auf dem ich hier gerade diesen Text schreibe und zum zweiten habe ich einen Notebook, der mich begleitet, wenn ich mal unterwegs bin. Auf dem Standrechner habe ich den MySQL-Server installiert. Sowohl auf Standrechner, als auch auf dem Notebook habe das BVASystem installiert und so eingerichtet, das beide Rechner auf das Serverprogramm des Standrechners zugreifen können.

Ein Nachteil ist es, das auch, wenn man nur von einem Rechner aus seine Fotos verwalten will, man den Datenbankserver installieren muss. Gerade für Nutzer, die nicht so technikaffin sind, könnte es zu Schwierigkeiten in der Administration des Servers kommen. Auch ich hatte schon so meine Schwierigkeiten mit dem MySQL-Server: Server has gone away Weiterhin kann es von Nachteil sein, wenn man mit mehreren Clients auf die Fotos zugreifen will und dafür extra einen Rechner bereitstellen muss auf dem nur der Server läuft.

Ein weiterer Vorteil, für mich als Entwickler ist, das ich mit dem Client-Server-Modell auf standardisierte Server-Komponenten zurückgreifen kann. Damit lässt sich wunderbar, das von mir bereits beschriebene Schichtenmodell umsetzten. Ich muss also weniger Aufwand in die Entwicklung des Systems stecken. Aber auch für den Anwender hat dies einen Vorteil. Wenn ich morgen, aus welchem Grund auch immer, das BVASystem nicht mehr weiterentwickeln würde, dann könnte der Anwender weiterhin mit Service-Programmen, die mit dem Server ausgeliefert werden, auf seine Daten zugreifen und sie in eine Struktur überführen, die andere Programme lesen können.

Als nachteilig empfinde ich es, das die Bilder, die ich in der Datenbank gespeichert habe, nicht so ohne weiteres Bearbeiten kann. Wenn ich von mehreren Rechnern auf die Bilder zugreifen will, so muss ich diese direkt in der Datenbank abspeichern. Zur Bearbeitung muss ich die Bilder also erst aus der Datenbank extrahieren und anschließend wieder neu abspeichern. Um diesen Nachteil auszugleichen, hatte ich damals vor, das BVASystem mit Bildbearbeitungsfunktionen auszustatten. Mittlerweile bin ich davon aber weg gekommen, da dies den Rahmen eines Hobbyprojektes bei weitem sprengen würde.