Wissen ist Macht; allerdings: Daten zu haben ist das Eine, sich in ihnen zurecht zu finden aber der andere wichtige Teil. Während es für Profis, die mit großen Datenmengen desselben Typs hantieren, relativ einfach ist und vorgefertigte Lösungen gibt, muss sich der Privatmann selber darum kümmern. Aber wie organisiert man seine Daten sinnvollerweise? Und wie kann man seine Daten überhaupt sinnvoll klassifizieren? Eine endgültige Antwort habe ich auch nicht, aber ich dokumentiere hier meinen derzeitigen Stand der Erfahrung.
Projekte: Als „Projekt“ bezeichne ich alles, was vom Umfang her abgeschlossen ist, jedoch nicht zeitlich (d.h. ein Projekt kann sich über lange Zeit erstrecken und findet nicht unbedingt ein Ende). Alle Dateien, die zu einem Projekt gehören, kommen in ein gemeinsames Verzeichnis.
Dokumente: Das sind alle „isolierte Dateien“, die keinem Projekt zuzuordnen sind, sondern für sich alleine stehen – z.B. Briefe, Grafiken, Rechnungen usw. Man kann sie nach Erstellungszeitpunkt gruppieren, d.h. alle Dokumente aus einem Jahr kommen in ein gemeinsames Verzeichnis. Für häufige Untergruppierungen sind Unterverzeichnisse möglich. Um auch ohne spezielles Client-Programm die Dokumente anschauen zu können, erstelle ich für jedes Nicht-Klartext-Dokument eine PDF-Datei.
E-Mail: Mails sortiert man am besten sowohl nach Inhalt (z.B. private Mails, Newsletter,
Mailinglisten, geschäftliche Mails) als nach Zeitpunkt (z.B. nach Jahren gruppiert). Meine Mails
werden auf dem IMAP-Server im Maildir-Format gelagert => standardisierter Zugriff, einfach
durchsuchbar.
Ein Sonderfall sind Attachments; auf die will man normalerweise direkt zugreifen,
statt erst alle Mails durchsuchen zu müssen. Daher speichere ich alle eingehenden und ausgehenden
Attachments in Verzeichnissen nach Jahren gruppiert und sortiert nach dem Datum (d.h. Unterverzeichnisse
mit Datum und Beschreibung des Attachments als Verzeichnisnamen).
Konfiguration: Vor allem unter Unix sind die Programme typischerweise extrem flexibel konfigurierbar, außerdem wird sämtliche Konfiguration in Klartextdateien gespeichert. Man will die Konfiguration also speichern, um sie bei einer Neuinstallation retten oder auf andere Rechner klonen zu können. Man erstellt sich also sozusagen ein ein zentrales „/etc/skel“-Verzeichnis, in dem sie alle gesammelt werden.
Adressbuch: Weil man Adressen immer zur Hand haben will und gleichzeitig normalerweise immer nur
manuell darauf zugreift (wer schreibt schon im privaten Umfeld regelmäßig Serienbriefe), habe
ich meine Adressen auf dem PDA in dessen proprietärer Adressdatenbank.
Zu überlegen wäre noch eine Möglichkeit, wie man „erweiterte Daten“
übersichtlich unterbringt; Anwendungsbeispiel: Man lernt gelegentlich Leute kennen, von denen man
kaum Daten hat (z.B. keine Postdresse), mit denen man vorerst nicht kommunizieren wird, aber von denen
man trotzdem etwas speichern will (Name, Ereignis des Kennenlernens, Zusatznotizen), um sich besser an
sie erinnern zu können („das ist der Tandemfahrer, der auch schon mal in Nordspanien
war“) – diese Dinge haben zwar einerseits Bezug zu Personen, müssen andererseits nicht
unbedingt das Adressbuch aufblähen.
Terminplaner: Hier will man nach verschiedenen Arten von Terminen unterscheiden – wichtige persönliche Termine (in verschiedenen Kategorien, z.B. privat, geschäftlich usw.), fakultative Termine (z.B. monatlicher Stammtisch, interessanter Diavortrag), „Markierungen“ (wichtige Tage, denen man ein Datum zuordnen können will, z.B. Feiertage, Ferienbeginn) und „Logbucheinträge“ (wo man einträgt, was man wann getan hat, um es später nachvollziehen zu können).
Notizen: Momentan habe ich meine Notizen auf dem PDA als Klartext. Für jeden Themenbereich
gibt es eine eigene Datei (privat, Projekte, Uni, Reisen), und dort jeweils Unterkategorien, was im
Prinzip ausreicht, um sich halbwegs zurechtzufinden.
Eine interessante Option wäre ein Wiki, mit dem man die Notizen nicht nur eindimensional in gewisse
Kategorien einteilen kann, sondern multidimensional untereinander verlinken kann. Dazu wäre ein PDA
erforderlich, auf dem sich ein Wiki sinnvoll betreiben lässt.
Ein Sonderfall von „Notizen“ sind Daten, die zwar „unterwegs“ anfallen, aber vorwiegend zu Archivierungszwecken gesammelt werden – z.B. Auto-Fahrtenbuch. Hier interessiert die Durchsuchbarkeit nicht; aber Archivierung erfordert eine gute Exportierbarkeit in Standardformate, außerdem will man damit vielleicht Data Mining betreiben. Bei großen Datenmengen würde das im Prinzip für eine Datenbank sprechen, in der Praxis zumindest für sauber sortierte Tabellen.
PIN-Codes usw.: Die will man auch immer zur Hand haben, darum sind die verschlüsselt auf meinem PDA gespeichert. Das proprietäre Format ist ok, weil man nur manuell darauf zugreift.
Bookmarks: Bookmarks braucht man bei Internet-Recherchen, deshalb macht es Sinn, sie im Internet aufzubewahren. In meinem Fall in einer Datenbank, die die Bookmarkliste in HTML ausgibt und das Durchsuchen ermöglicht; das Hinzufügen geht per Web-Interface, oder automatisiert per Bookmarklet.
Digitalfotos: Dank EXIF-Daten und Dateinamen, die das Datum enthalten, kann man Digitalfotos
leicht chronologisch ordnen. Das Suchen von Motiven gelingt aber nur mit Zusatzinformationen, d.h. man
müsste eine Datenbank erstellen und dort jedem Bild eine Kategorie und eine Kurzbeschreibung
zuordnen.
Mit Hilfe der Zeitachse ließe sich theoretisch eine Verknüpfung mehrere
Datenquellen machen, d.h. der Terminkalender ordnet dem Foto ein Ereignis zu, und die GPS-Datenbank
einen Ort.
GPS-Tracks: Tracks müssen v.a. archiviert werden (d.h. man muss nicht häufig darauf zugreifen), und zwar gut kommentiert (Datum, Ereignis, Besitzer des Tracks). Außerdem kann man Tracks nur graphisch beurteilen, d.h. man will sie automatisiert in Karten einzeichnen können sowie zur Weiterverwendung in Vektor- und GIS-Formate exportieren. Darum bietet sich auch für GPS-Tracks eine Datenbank an.
Gleichförmige Daten, die häufig exportiert oder rekombiniert werden müssen, kommen in die Datenbank.
Daten in vielen unterschiedlichen Formaten sammelt man in Verzeichnissen und speichert man zusätzlich in einem häufig anzutreffenden Format, um notfalls auch ohne Spezialsoftware zugreifen zu können. Für eine benutzbare Suchfunktion kann es sich lohnen, einen Such-Index über diese Daten anzulegen.
Daten, auf die man nur manuell zugreift, kann man in proprietären Formaten speichern.
Haarig wird es immer dann, wenn die gleichen Daten auf unterschiedlichen Rechnern sind, aber in verschiedenen Versionen vorliegen können.
Einerseits ist es wünschenswert, viele Kopien zu haben, alleine schon aus Backup-Gründen, aber auch, um seine Daten überall verfügbar zu haben (auch ohne Direktzugriff auf einen zentralen Speicher). Andererseits macht das eine automatische Synchronisierung praktisch unmöglich – man kann nicht zwei Computer untereinander abgleichen, wenn die Daten noch auf weiteren Geräten sind, auf die u.U. momentan kein Zugriff besteht.
Eine Synchronisation aller Rechner gleichzeitig ist oft unpraktikabel (v.a. wegen mangelnder Erreichbarkeit oder zu geringem Datendurchsatz), und eine iterative Synchronisation jeweils zweier Rechner (so lange, bis alle Rechner auf dem gleichen Stand sind), ist ein großer Aufwand.
Lösung, Teil 1: Jede Datei ist auf einem bestimmten Rechner „zu Hause“ (z.B. Office-Dokumente auf dem Desktop-Rechner, Webseiten auf dem Webserver etc.) – das reduziert die Anzahl der nötigen Vergleiche drastisch, weil grundsätzlich die Daten, die auf ihrem „Heim-Rechner“ sind, jene auf den anderen Rechnern überschreiben dürfen.
Lösung, Teil 2: Ich kopiere Daten, bevor ich sie verändere, zuerst in einen „Ausgangskorb“ – dann muss ich nur noch den Inhalt dieses Ausgangskorbs mit den anderen Rechnern (v.a. dem Heim-Rechner der Daten) abgleichen (und kann das auch über Umwege tun, d.h. eine aktualisierte Datei zuerst in den Ausgangskorb eines zweiten Rechners kopieren, bevor ich sie von dort aus auf den Heim-Rechner bringe), und habe außerdem in Zweifelsfällen nicht nur die veränderten Dateien verfügbar, sondern gleichzeitig noch die Ursprungsversionen, von denen sie abstammen.
Lösung, Teil 3: Außerdem lege ich auch auf allen Rechnern einen „Eingangskorb“ an – Dateien, die ich hinüberkopiere, muss ich dann nicht gleich einsortieren, sondern kann sie erst einmal in den dortigen Eingangskorb schieben; erst wenn ich auf dem jeweiligen Rechner arbeite, muss ich mich um das Einsortieren bemühen (zuvor gibt es keinen Grund, sie auf die Verzeichnisstruktur eines Rechners zu verstreuen).
Diese Vorgehensweise macht ein rein manuelles Backup handhabbar.
Datenbanken sind von sich aus mehrbenutzerfähig, weil die Operationen (idealerweise) atomar sind und die Daten nicht-redundant gespeichert werden. Man braucht nur noch eine Benutzerverwaltung.
Dateien sind kaum sinnvoll gemeinsam zu bearbeiten. Bei seltenen Änderungen und wenigen
Benutzern (so dass Bearbeitungskonflikte nicht auftreten) kann es reichen, die Datei online erreichbar
zu speichern und zu definieren, dass die dortige Kopie stets als die aktuelle Version zu gelten hat
– vor der lokalen Bearbeitung muss stets eine neue Kopie von dort geholt werden, es werden
keinesfalls mehrere lokale Kopien unterhalten.
In den meisten Fällen dürfte jedoch ein Versionsverwaltungssystem wie Subversion die
bessere Lösung darstellen.
Manchmal ist eine dateiorientierte Speicherung unpassend, weil es nicht auf ein bestimmtes Dateiformat ankommt, sondern darauf, dass man flexibel Zugriff auf die Daten hat (von überall her) und sie leicht ändern oder durchsuchen kann. Hier bietet sich spezielle Software mit Versionsverwaltung an; für textorientierte Daten (z.B. Logbuch über die Systemkonfiguration) beispielsweise ein Wiki, und für andere Datentypen entsprechende Groupware-Lösungen (z.B. Online-Kalender, -Adressbuch). Dies betrifft wohl alle Daten, die nicht dateiorientiert gespeichert werden müssen und nicht per se in einer Datenbank steckt, also beispielsweise all das, was ein Einzelner auf seinem PDA speichern würde.
Für den Sonderfall, dass die Daten nur von einem Benutzer geschrieben werden (jedoch von vielen gelesen werden), reicht oft auch eine normale Webseite. Eine ausgefeilte Versionsverwaltung ist dann überflüssig (weil sich nicht mehrere Edits ins Gehege kommen), die Seite ist nur in genau einer Version vorhanden und von überall zu erreichen (evtl. mit Passwortschutz). Ideal für Daten eines Benutzers (bzw. eines engen Benutzerkreises), die für viele andere Nutzer interessant sein können und darum veröffentlicht werden.
Generell erfordern Lösungen für mehrere Benutzer, dass nicht (zumindest nicht dauerhaft) mehrere Kopien der Daten vorhanden sind, sondern immer mit einem zentralen Datenbestand gearbeitet wird. Synchronisation ist damit nicht nötig, da es auch nicht praktikabel wäre.
E-Mail: Neben den oben erwähnten inhaltlichen Kategorien habe ich noch zwei weitere Ordner, in die ich meine Mails einsortiere. In einen kommen Kopien aller Mails, die ich beantworten muss; in den anderen Kopien der Mails, die ich geschrieben habe, und auf die ich Antworten erwarte.
Fotos: Im Unterschied zu einer klassischen Foto-Datenbank gibt es auch die Fälle, dass es mehrere Versionen eines Fotos gibt (z.B. Originalversion und mehrere nachbearbeitete bzw. verfremdete Versionen) oder auch mehrere Bildbeschreibungen zu einem Foto (z.B. wenn in verschiedenen Online-Foto-Galerien verschiedene Aspekte eines Bildes interessieren, etwa einerseits der abgebildete Gegenstand und andererseits die Umgebung und Stimmung).