Posts Tagged ‘Datenbank’

Datenbanksystem-Unterschiede 4

Mittwoch, März 28th, 2012

Heute möchte ich meine kleine Datenbanksystem-Unterschied-Serie zum Abschluss bringen.  Als letztes geht es um einen kleinen SQL-Befehl, der im Gegensatz zu den anderen Unterschieden, im alltäglichen Betrieb benötigt wird. Es geht um die Frage:

Wie kann ich die Datensatz-ID des zuletzt gespeicherten Datensatzes erhalten?

Fügt man in eine beliebige Tabelle mit Hilfe eines „INSERT INTO …“-Befehls einen Datensatz hinzu, so weiß man im Normalfall nicht, welcher Wert per Autoincrement/Trigger für das ID-Feld generiert wurde. Diesen Wert benötigt man allerdings, wenn weitere Daten in einer abhängigen Tabelle (foreign keys) gespeichert werden sollen.

Eine Lösung wäre, das man den gerade eingefügten Datensatz wieder selektiert und das ID-Feld ausliest. Dies ist aber nicht notwendig, da alle 3 Datenbanksysteme für diesen Fall eine einfachere Lösung bieten.

MySQL

MySQL besitzt eine Funktion, mit der man die zuletzt hinzugefügte ID erfragen kann. Der Funktionsaufruf ist per SELECT-Befehl möglich und sieht wie folgt aus:

SELECT LAST_INSERT_ID() AS ID

Wichtig ist hier, das der Befehl gleich nach dem INSERT aufgerufen wird, da sich der Wert bei einem weiteren INSERT ändert.

Firebird

Bei Firebird kann man den zur Datenbanktabelle gehörenden Generatorwert erfragen. Es ist ein wenig aufwendiger als bei MySQL, da man für unterschiedliche Tabellen unterschiedliche Generatoren abfragen muss. Die Abfrage sieht wie folgt aus:

SELECT gen_id(GEN_BVA_CREATIONTREE, 0) AS ID from rdb$Database

Vorteil ist hier, das der Generatorwert jederzeit abgefragt werden kann. Auch ohne INSERT kann der aktuelle Wert des Generators abgefragt werden.

Oracle

Mit einer ähnlichen Abfrage kommt man bei Oracle zu seinem ID Wert.  Sie sieht wie folgt aus:

SELECT GEN_BVA_CREATIONTREE.CURRVAL AS ID FROM DUAL

 

Datenbanksystem-Unterschiede 3

Donnerstag, März 22nd, 2012

Im letzten Teil war bereits für Firebird und Oracle ein Datenbanktrigger enthalten, der die Aufgabe hatte, das Auto-ID Feld zu füllen. Der Vollständigkeit halber möchte ich heute einen einfachen Trigger für alle 3 Datenbanksysteme vorstellen. Da die syntaktischen Unterschiede zwischen den Triggern nicht größer sein könnten, werde ich die 3 SQL-Befehle relativ unkommentiert im Raum stehen lassen. Die Möglichkeiten des einzelnen Datenbanksystems sind in den jeweiligen Dokumentationen besser erfasst. Bevor ich jetzt auf die 3 Datenbanksysteme eingehe, möchte ich aber kurz erläutern was ein Trigger ist.

Was ist ein Trigger?

Ein Datenbanktrigger ist eine Datenbankfunktionalität, die in eigentlich jedem größeren Datenbanksystem integiert ist. Man kann sich einen Trigger wie ein kleines Programm vorstellen, das bei bestimmten Datenbankaktionen ausgeführt wird. Beispielsweise kann vor dem Einfügen eines Datensatzes geprüft werden, ob die Daten valide sind. Oder es wird ein Trigger erstellt, der das Erstellungsdatum des Datensatzes speichert.

Genau so ein Trigger soll mein Beispiel für den Vergleich zwischen MySQL,Firebird und Oracle sein. In der Tabelle bva_image speichert der Trigger in dem Feld mod_date das aktuelle Systemdatum ab, sobald ein Datensatz in der Tabelle hinzugefügt wird.

Trigger unter MySQL

CREATE TRIGGER  bva_image_insert_timestamp
 BEFORE INSERT on bva_image
 FOR EACH ROW
  SET NEW.mod_date = NOW();

Trigger unter Firebird

CREATE TRIGGER bva_image_insert_timestamp FOR bva_image
 BEFORE INSERT
 AS
 BEGIN
  NEW.mod_date = CURRENT_TIMESTAMP;
 END

Trigger unter Oracle

CREATE OR REPLACE TRIGGER IMAGE_INSERT_TIMESTAMP
 BEFORE INSERT ON BVA_IMAGE
 FOR EACH ROW
 BEGIN
  :new.mod_date := SYSDATE;        
 END;

Störrische Datenbanksysteme

Samstag, März 17th, 2012

Eigentlich wollte ich heute hier berichten, das das BVASystem 2.1.0.39-dev nun 3 verschiedene Datenbankmanagementsysteme unterstützt. Leider gab es in den letzten Tagen eine Reihe von Problemen, so das es aktuell nur 2 Datenbanksysteme (MySQL und Firebird) sind. In der nächsten Version werde ich Oracle als drittes Datenbanksystem nachreichen.

Probleme mit Firebird

Schon zu Beginn der Arbeiten zur neuen Version des BVASystems gab es die ersten Probleme. Firebird nutzt ein komplett anderes System um eine Datenbankverbindung aufzubauen als MySQL oder Oracle. Firebird benötigt den Pfad und Dateinamen der Datenbankdatei, um eine Verbindung herzustellen. Da ich Pfad und Dateiname im Administrationstool nicht erfasst habe, war es mir nicht möglich, für alle 3 Datenbanksysteme den gleichen Einstellungsdialog zu verwenden. Also musste ich in den sauren Apfel beißen und einen weiteren Einstellungsdialog entwickeln.

Das zweite Problem war, das auch später im BVASystem immer wieder der Pfad und der Dateiname der Datenbank benötigt wird. Da ich dies absolut nicht wollte, habe ich recht lange nach einer Lösung gesucht und auch eine gefunden. Die Lösung heißt: „aliases.conf“ Im Programmverzeichnis von Firebird liegt eine aliases.conf, in der ein Alias für eine Kombination aus Pfad und Dateiname angelegt werden kann. Das BVASystem Administrationstool legt den benötigten Alias, bei der Erstellung der Datenbankstruktur, mit an. Die einzige Aufgabe, die manuell ausgeführt werden muss, ist ein Neustart des Datenbankservers. Ohne Neustart steht der neue Alias noch nicht zur Verfügung und die Datenbankverbindung schlägt fehl.

Probleme mit Oracle

Auch Oracle erwies sich als nicht weniger störrisch. Die notwendigen Datenbankscripte waren relativ schnell entwickelt, aber bei der von mit genutzten Version 9 lassen sich absolut keine Trigger erzeugen. Per SQLPlus funktionieren die einzelnen Befehle der Scripte wunderbar, aber beim Administrationstool werden vom ODBC-Treiber die Zeilenwechsel durch einen doppelten Wagenrücklauf (#13) ersetzt. Oracle schimpft dann bei der Übersetzung der Trigger, das ein ungültiges Zeichen gefunden wurde. Tests mit der Version 10 funktionierten dagegen einwandfrei. Daher habe ich mich entschlossen, die Unterstützung von Oracle 9 wieder zu entfernen bzw. sie durch Version 11 zu ersetzten. Da ich dafür allerdings mindestens 1 Woche benötige, habe ich entschieden, Oracle auf die nächste Programmversion zu verschieben. Ich hoffe, das dies dann das letzte Problem war, auf dem Weg zur Unterstützung von 3 Datenbanksystemen.

Ausblick

Neben der Oracle Unterstützung habe ich vor, noch einen Programmfehler aus dem BVASystem zu entfernen. Zum Beispiel stürzt das Programm leider ab, wenn ein Bild mit fehlerhaften Exif-Header geladen wird. Außerdem habe ich vor, die Installationsanleitung anzupassen, da nun die Erstellung der Datenbank mit dem Administrationstool einfacher geworden ist.

 

Datenbanksystem-Unterschiede 2

Freitag, März 16th, 2012

Im zweiten Teil meiner kleinen Serie soll es nun um die Definition eines Auto-ID Feldes gehen. Ein Auto-ID Feld ist ein Datenbankfeld, welches automatisch, beim Einfügen eines neuen Datensatzes, gefüllt wird. Meist wird für diese Zwecke ein Zahlenfeld genutzt. Der erste Datensatz erhält die ID 1, der zweite die 2, der dritte die 3 usw. Benötigt werden die Auto-ID Felder recht häufig, da mit ihnen Verknüpfungen zu anderen Datenbanktabellen, so genannte „Foreign Keys“, hergestellt werden können.

Auto-ID Feld unter MySQL

Wie einfach es ist, unter MySQL ein Auto-ID Feld zu erzeugen, hatte ich bereits im Teil 1 erwähnt. Man muss nur bei der Erzeugung einer Tabelle beim gewünschten Feld das Schlüsselwort AUTO_INCREMENT hinzufügen. Als Datenbankentwickler freut man sich sicher, das man so schnell fertig ist.  Aber man stößt sehr schnell an eine Grenze, wenn man komplexere Sachen umsetzen möchte. Zum Beispiel ist es nicht ohne weiteres möglich, eine eindeutige ID über mehrere Tabellen zu definieren.

Auto-ID Feld unter Firebird

Unter Firebird sind mehrere Einzelschritte notwendig, um ein Auto-ID Feld zu definieren. Als erstes wird logischerweise wie in Teil 1 bereits beschrieben die Tabelle angelegt. Als zweiten Schritt erzeugt man sich einen sogenannten Generator, der die jeweils zuletzt genutzte ID speichert. Die Erzeugung eines Generators erfolgt mit folgendem SQL-Befehl:

CREATE GENERATOR GEN_BVA_CREATIONTREE

Als nächstes muss der Generator mit einem Wert initialisiert werden. Im Beispiel wird der Generator mit dem Wert 0 initialisiert.

SET GENERATOR GEN_BVA_CREATIONTREE TO 0

Als letztes und wichtigstes Element wird ein Trigger benötigt, der vor dem Einfügen eines Datensatzes ausgeführt wird. Der Trigger erhöht den Generatorwert um 1 und trägt den Wert in das gewünsche Auto-ID-Feld der Tabelle ein.

CREATE TRIGGER ID_TRIGGER_BVA_CREATIONTREE FOR BVA_CREATIONTREE
 BEFORE INSERT
 AS
 BEGIN
  NEW.ID = GEN_ID(GEN_BVA_CREATIONTREE,1);
 END

Hier ist es möglich über mehrere Tabellen einen eindeutigen Index zu erzeugen. Dafür muss man in den jeweiligen Triggern den gleichen Generator nutzen.

Auto-ID Feld unter Oracle

Oracle arbeitet prinzipiell nach dem gleichen Konzept wie Firebird. Allerdings heißt der Generator bei Oracle Sequenz. Außerdem entfällt der Initialisierungsschritt, da die Initialisierung bereits bei der Erstellung der Sequenz erfolgt. Die Befehlsfolge für Oracle sieht wie folgt aus:

CREATE SEQUENCE GEN_BVA_CREATIONTREE
 START WITH 1
 INCREMENT BY 1
 NOMAXVALUE
 NOCACHE
 ORDER;
CREATE OR REPLACE TRIGGER ID_TRIGGER_BVA_CREATIONTREE
 BEFORE INSERT ON BVA_CREATIONTREE
 FOR EACH ROW
 BEGIN
  SELECT GEN_BVA_CREATIONTREE.nextval INTO :new.id FROM DUAL;
 END;
/

Datenbanksystem-Unterschiede 1

Dienstag, März 13th, 2012

Vor einiger Zeit schrieb ich, das eine Datenbankverbindung per ODBC den Vorteil hat, das sie für jedes Datenbanksystem funktioniert, welches ODBC unterstützt. Aktuell, nach der Entwicklung des Administrationstools, muss ich diese Aussage leicht korrigieren. Richtig ist, das die Standard SQL-Befehle, wie SELECT, INSERT, UPDATE usw, mit jedem Datenbanksystem genutzt werden können. Nutzt man allerdings speziellere Dinge wie zum Beispiel SQL-Befehle zum Anlegen von Datenbanktabellen, dann unterscheidet sich die Syntax von Datenbanksystem zu Datenbanksystem.

Da ich gerade beim Schreiben der Scripte zum Erstellen der BVASystem-Datenbankstruktur für MySQL, Firebird und Oracle bin, möchte ich heute eine kleine Serie starten, welche die Unterschiede zwischen diesen 3 Datenbanksystemen zusammenfasst. Dabei werde ich allerdings nur auf die Unterschiede eingehen, die mir im Zusammenhang mit dem BVASystem aufgefallen sind.

Starten möchte ich heute mit den unterschiedlichen Syntax des SQL-Befehls „CREATE TABLE“. Im folgendem werde ich an der Tabelle „bva_creationtree“ zeigen, wo die  Unterschiede zwischen den Datenbanksystemen liegen.

CREATE TABLE unter MySQL

Richtig bequem finde ich bei MySQL die Möglichkeit ein Auto-ID Feld zu generieren. Hierfür muss einfach neben das gewünschte Feld das Schlüsselwort „AUTO_INCREMENT“ geschrieben werden. Bei Firebird und Oracle werden die Auto-ID Felder über eine Kombination aus Generator/Sequenz und Trigger gelöst. Damit dieser Blog nicht zu unübersichtlich wird, werde ich im nächsten Teil noch einmal ausführlich auf das Thema eingehen.

Als zweite Besonderheit bei MySQL fällt auf, das am Ende des Befehles eine „Engine“ ausgewählt werden kann. MySQL unterstützt unterschiedliche Speicherengines. Je nach Einsatzzweck unterscheiden sich die Speicherengines in ihrer Performance. Da mir die Transaktionssicherheit recht wichtig ist, nutze ich die langsamere InnoDB-Engine.

Der komplette SQL-Befehl für die bva_creationtree Tabelle sieht wie folgt aus:

CREATE TABLE bva_creationtree (
 id INT NOT NULL AUTO_INCREMENT,
 parent_id INT ,
 caption VARCHAR(10)  NOT NULL,
 PRIMARY KEY (id),
 INDEX fk_bva_creationtree (parent_id ASC),
 CONSTRAINT fk_bva_creationtree
   FOREIGN KEY (parent_id)
   REFERENCES bva_creationtree (id)
) ENGINE = InnoDB

CREATE TABLE unter Firebird

Schaut man sich den gleichen SQL-Befehl für Firebird an, so sieht er auf dem ersten Blick relativ ähnlich aus.

CREATE TABLE bva_creationtree (
 id INT NOT NULL,
 parent_id INT,
 caption VARCHAR(10) NOT NULL,
 PRIMARY KEY (id),
 CONSTRAINT fk_creationtree
   FOREIGN KEY (parent_id)
   REFERENCES bva_creationtree (id)
 )

Auf dem zweiten Blick fällt dann auf, das für den Fremdschlüssel „fk_creationtree“ kein zusätzlicher Index definiert wurde. Der zusätzliche Index ist bei Firebird nicht notwendig, da er mit dem Constraint zusammen anglegt wird. Das Auto-ID Feld „id“ muss wie bereits beschrieben manuell angelegt werden. Ansonsten gibt es keine weiteren Unterschiede.

CREATE TABLE unter Oracle

Größere syntaktische Unterschiede gibt es bei Oracle. Als erstes fällt auf, das sich die Datentypbezeichnungen unterscheiden: NUMBER(38) anstelle von INT, VARCHAR2() anstelle von VARCHAR() und INT anstelle von FLOAT. Bequem ist, das einfache Primärschlüssel oder auch Constraints direkt hinter der Felddefinition angegeben werden können. Alternativ können sie aber  beispielsweise auch per „CONSTRAINT pk_creationtree PRIMARY KEY (id)“ angelegt werden.

Nach dem Ende des eigentlichen Create Table SQL-Befehlt gibt man bei Oracle an, in welchem Tablespace die Daten der Tabelle gespeichert werden sollen und wie die Tabelle sich verhalten soll, wenn sie zusätzlichen Speicher benötigt. Die dort getätigten Einstellungen haben Auswirkungen auf die Performance. Speichert man große Datenmengen in einer Tabelle, ist es sinnvoll sie in größeren Schritten zu vergrößern, da die Vergrößerung dann nicht mit jedem neuen Datensatz durchgeführt werden muss.

Der vollständige SQL Befehl für die Beispieltabelle sieht wie folgt aus:

CREATE TABLE bva_creationtree (
 id NUMBER(38) NOT NULL PRIMARY KEY,
 parent_id NUMBER(38),    
 caption VARCHAR2(10) NOT NULL,
 CONSTRAINT fk_creationtree
   FOREIGN KEY (parent_id)
   REFERENCES bva_creationtree (id)  
 )
 TABLESPACE bva
 STORAGE
  ( INITIAL     1M
    NEXT         1M
    PCTINCREASE 0
    MINEXTENTS     1
    MAXEXTENTS     UNLIMITED
  )

Das neue BVASystem Administrationstool

Sonntag, Januar 22nd, 2012

Mit der heutigen Programmaktualisierung befindet sich nun ein weiteres, zweites Programm in dem BVASystem-Installationspaket: Das BVASystem Administrationstool. Mit diesem Tool sollen später alle verwaltungstechnischen Datenbankaufgaben erledigt werden, wie zum Beispiel das Aktualisieren der Datenbankstruktur nach einem Softwareupdate. Aber gut, da noch keinerlei Datenbank-Strukturänderungen in Sicht sind, denn wenn man das Administrationstool startet, wird man es sehr schnell wieder schließen. Außer dem Beenden des Administrationstools ist noch keine weitere Funktionalität implementiert. Trotzdem steckt schon ein gutes Stück Arbeit drin, denn das Administrationstool ist, wie auch das BVASystem, mehrsprachen fähig. Die dafür notwendigen Konfigurationen habe ich für das Administrationstool erstellt und an einigen wenigen Zeichenketten umgesetzt.

Warum ich mich gerade jetzt entschlossenen habe, mit dem Administrationstool zu beginnen, habe ich im letzten Blog bereits kurz umrissen. Heute möchte ich näher auf die Funktionen eingehen, die ich mir für das Administrationstool vorstelle.

Einstellung von systemweiten Programmparametern

In der Konfigurationsdatei des BVASystems gibt es einige Parameter, die sich direkt auf die Datenbank auswirken. Zum Beispiel kann die Miniatur- und Vorschaubildgröße eingestellt werden. Da sowohl Miniatur- und Vorschaubilder in der Datenbank abgelegt werden, ist es wenig sinnvoll, wenn man diese Parameter jederzeit im Programm ändern kann.  Ich denke, das Administrationstool dagegen ist ein guter Platz um diese globalen Parameter einzustellen.

Datenbanksystem festlegen

Ich bin gerade dabei, das BVASystem so umzustellen, das es mehrere verschiedene Datenbanksysteme unterstützt. Welches Datenbanksystem der Client nutzen soll, wird im Administrationstool einstellbar sein.

Anlegen von Datenbanknutzern

Nach man sich auf ein Datenbanksystem festgelegt hat und der Server installiert ist, sollte noch mindestens 1 Datenbanknutzer angelegt werden, über den der Zugriff auf die BVASystem-Datenbank erfolgt.

Datenbankstruktur erstellen

Die wohl wichtigste Aufgabe des Administrationstools wird es sein, die für das BVASystem benötigte Datenbankstruktur zu erstellen. Die dafür notwendigen Datenbankscripte werden in das Tool integriert, so das ihr eigentlich nur noch auf „Start“ drücken müsst.

Datenbankstruktur aktualisieren/anpassen

Wer einmal begonnen hat, mit dem BVASystem zu arbeiten, möchte natürlich auch neuere Versionen nutzen können, ohne das alle Daten neu eingestellt werden müssen. Von daher ist es wichtig, das ältere Datenbankstrukturen an neue Anforderungen angepasst werden können.

Backup und Wiederherstellung des Datenbestandes

Ebenfalls eine wichtige Funktion ist es, das beispielweise vor einer Datenbankstrukturänderung die Daten für den Notfall gesichert werden können.  Generell sollte aber jedem im klaren sein, wie sinnvoll bzw. wie notwendig regelmäßige Backups sind.

Welche dieser Funktionen wann verfügbar sein werden, kann ich noch nicht genau sagen. Aktueller Arbeitsschwerpunkt ist, das unterschiedliche Datenbanksysteme untersützt werden. Dafür benötige ich die Datenbanksystemauswahl und das Erstellen der Datenbankstruktur. Datenbankaktualisierungen sind vorerst keine in Sicht und für Backup/Restore kann man aktuell notfalls auf Datenbanksystem-Tools zurückgreifen.

Weitere Neuerungen

Auch wenn ich schon recht viel geschrieben habe, möchte ich noch kurz auf die weiteren Änderungen eingehen. In der Miniaturbilder und Filmstreifenansicht wurde der Werkzeugbuttonbereich komplett überarbeitet. Die Knöpfe werden nun genauso dargestellt, wie in den restlichen Menüleisten. Außerdem wurde das Bild beim Knopf zum Markieren eines Fotos ausgetauscht, da das alte „+“ als „Bild importieren“ missverstanden werden konnte. Neu ist ebenfalls der Knopf, der das zukünfige Popup-Bildinformationen-Fenster öffnet.

In den nächsten Tagen werde ich einen weiteren Blog zum PopUp-Fenster schreiben, in dem ich erkläre, wie man so einen Dialog implementieren kann. Außerdem habe ich jetzt eh bereits viel zu viel geschrieben :-D

Lizenzierung Teil 3

Montag, November 28th, 2011

Mit der ab heute verfügbaren Version 2.0.0.31, ist das Lizenzsystem endlich abgeschlossen. Dafür, das ich darin möglichst wenig Arbeit stecken wollte, hat es mich doch eine ganze Weile beschäftigt. Dabei sind mir Inhalte eigentlich wichtiger, als so verwaltungstechnischer Kram. Aber nun ist es ja abgeschlossen und wird mich hoffentlich nicht so schnell wieder belästigen.

Der wichtigste Änderungspunkt an der neuen Version ist wohl, das ich Änderungen an der Datenbankstruktur vorgenommen habe. Ihr müsst also einmal wieder eure Datenbank aktualisieren oder neu erstellen. Die Änderungen werden zum Großteil in der aktuellen Version noch nicht genutzt. Sie sind hauptsächlich für die nächsten Punkte bestimmt, die ich im kommenden Jahr implementieren will. Ich möchte aber, das wenn ihr die stabile Software Version einsetzt, möglichst lange auch die Testversionen probieren könnt, ohne das ihr 2 verschiedene Datenbanken benötigt.  Theoretisch sollte dies jetzt auch die letzte Datenbankänderung sein, die per MySQL-Tools erledigt werden muss. Demnächst werde ich ein kleines Tool schreiben, mit dem ihr die Datenbankänderungen bequemer vornehmen könnt.

Bei der Fehlerkorrektur habe ich auch ein gutes Stück geschafft. Sogar einen hässlichen Totalabsturz, der bei einem fehlerhaften EXIF-Header auftrat konnte ich beseitigen. Entgegen meiner Ankündigung, das keinerlei neue Funktionen zu erwarten sind, habe ich 2 Kleinigkeiten umgesetzt, welche die Nutzbarkeit des Programmes doch merklich steigern.

Zum ersten kann nun, wenn der Eingabefocus auf einer der Bildkomponenten liegt, der Vollbildmodus mit der „Enter“ Taste geöffnet werden. Dadurch ist es nun möglich, das man den Vollbildmodus komplett per Tastatur bedienen kann. Die zweite Kleinigkeit betrifft die Sortierung der Bilder in den Bildlisten. Bisher war es so, das nach dem Programmstart eine Standardsortierung (Bildname aufsteigend) aktiv gewesen ist. Wollte man dauerhaft die Bilder anders sortiert haben, so musste man nach jedem Programmstart seine Wunschsortierung wieder einstellen. Nun ist es so, das beim Beenden des Programmes die aktive Sortierung gespeichert und beim nächsten Programmstart wieder aktiviert wird.

Zur Zeit sieht es danach aus, als wenn die nächste Updatemeldung hier für die erste stabile Version reserviert ist. Die Anzahl der gefundenen Fehler hält sich in Grenzen und es sind nur noch wenige Sachen an der Homepage zu erledigen. Ich hoffe, das es in 2-3 Wochen gut zu schaffen ist.

Braucht das BVASystem eine Nutzerverwaltung?

Dienstag, Februar 1st, 2011

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.

Der Logindialog

Freitag, Januar 21st, 2011

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

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

Die 14 dreht sich

Freitag, Januar 7th, 2011

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

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.