Ordnerstruktur für Benutzerdaten

Es ist mal wieder soweit. Unordnung hat sich in die Datenhaltung eingeschlichen. In über fünfundzwanzig Jahren die ich als Power User Windows- und Linux-PCs benutze, ist dieser Augenblick bereits öfter eingetreten. Und jedes mal habe ich etwas dazugelernt und meine Strukturen weiterentwickelt. In diesem Artikel beschreibe ich die Struktur, bei der ich aktuell angelangt bin.

Anforderungen #

• Die Ordnerstruktur soll sowohl kurzfristig als auch langfristig Daten aufnehmen können.
• Ich arbeite auf mehreren Geräten. Die Struktur muss lokale und verteilte Daten abbilden können, ohne für Verwirrung zu sorgen.
• Daten aus beruflicher Tätigkeit sollen sauber von privaten Daten getrennt sein.
• Wiederkehrende Muster in der Struktur sollen eine einheitliche Arbeitsweise etablieren und damit die mentale Belastung reduzieren.

Ordnungskriterien #

Die Struktur arbeitet mit zwei zentralen Ordnungskriterien. Das übergeordnete Ordnungskriterium ist der Kontext in dem die Daten anfallen, bzw. benötigt werden (z. B. Arbeit, Privat, Familie, Hobby, Temporär, etc.). Das untergeordnete Ordnungskriterium ist die Kategorie der Daten (z. B. Ressource, Projekt, Vorlage, Archiv, etc.).

Hinweis: Ein Anti-Pattern ist das Verwenden von Dateitypen als Ordnungskriterium. Z. B. Dokumente, Bilder oder Audio.
Dateien nach Typ zu ordnen, vereinfacht zwar die Gestaltung der Benutzeroberfläche eines Dateibrowsers. So kann z. B. die Bildvorschau standardmäßig im Bilder-Ordner eingeblendet werden. Eine Ordnung nach Dateityp kann aber nicht die tatsächlichen Zusammenhänge der Daten abbilden und führt deshalb schnell zu Unordnung. Deshalb ist der Kontext der Daten ein besserer Ansatz, um Ordnung zu schaffen.

Den Kontext von Daten zu bestimmen, fällt relativ leicht, da sich der Kontext an Begebenheiten der realen Welt orientiert. Für die meisten Daten ist er offensichtlich. Manchmal werden Daten jedoch kontextübergreifend genutzt. Dann kann für diesen Zweck ein gemeinsamer oder allgemeiner Kontext genutzt werden. Es kommt auch vor, dass Daten von einem Kontext in einen anderen überführt oder kopiert werden. Dies wird dann dadurch erleichtert, dass jeder Kontext die gleichen Kategorien und damit die gleiche innere Struktur verwendet.

Die Daten einer Kategorie zuzuordnen ist die größere Herausforderung für den Benutzer. Nach meiner Erfahrung hilft aber eine vordefinierte Liste, die nur bei sorgfältig geprüftem Bedarf erweitert wird. Und mit ein wenig Übung liegt in der klar zugeordneten Kategorie der Daten eine der größten Stärken der hier beschriebenen Ordnerstruktur.

Kategorien #

Die Kategorie beschreibt den typischen Umgang mit den Daten. Wird z. B. eine Datei heruntergeladen, die nicht verändert wird, aber in verschiedenen Projekten oder Arbeitsschritten genutzt wird, so ist sie eine Ressource. Wird eine Rechnung zur Aufbewahrung abgelegt, so ist sie ein Dokument für das Archiv. Gehören mehrere Dateien und Ordner zusammen, um eine bestimmte Aufgabe zu bewältigen, so bilden sie ein Projekt. Mache ich mir eine Notiz zu meiner aktuellen Tätigkeit, so kommt diese in mein Persönliches Protokoll.

Um die Kategorie von Daten zu erkennen, hilft es sich einige Fragen zu stellen:

• Werden die Daten bearbeitet oder nur gelesen?
• Haben die Daten einen festen zeitlichen Bezug?
• Gehören die Daten zu einer abgegrenzten Aufgabe oder einem Projekt?
• Wie lange und wie häufig werden die Daten voraussichtlich verwendet?

Weiter unten in der Beschreibung der Ebene 2 wird eine Liste vorgestellt, die sich bei mir bewährt hat.

Eine Kategorie hat mir besonders geholfen Ordnung in meinen Daten zu bewahren. In meinem Arbeitsalltag fallen immer wieder kurzfristig Daten an, die zu einer relativ kleinen Aufgabe, und nicht zu einem Projekt gehören. Die Aufgabe ist normalerweise in kurzer Zeit erledigt. Deshalb lohnt es sich auch nicht, ein neues Projekt dafür anzulegen. Diese Art von Daten haben bei mir die Kategorie Work Item. Jeder Arbeitgeber ist bei mir ein Kontext mit dem Unterordner workitems. In diesem lege ich dann für jeden Tag, an dem Daten der Kategorie Work Item anfallen, einen Unterorder an, der mit dem aktuellen Datum benannt ist. In diesem kontextbezogenen Tagesordner kann ich mehr oder weniger strukturiert alles ablegen, was ich kurzfristig benötige, ohne mich mit einer komplizierten Einordnung der Daten beschäftigen zu müssen.

Persistenzebenen #

Das Vorgehen für die Arbeit auf mehreren Geräten sieht eine manuelle Einordnung von Daten in drei Persistenzebenen vor. Jede Persistenzebene nimmt die gleiche Ordnerstruktur auf. Sie muss aber nicht in jeder Persistenzebene vollständig vorhanden sein. Ein Gesamtüberblick auf die Daten in einem Kontext ergibt sich also erst durch die gedankliche oder softwaregestützte Überlagerung aller Persistenzebenen.

• Lokal:
  Daten die entweder nur auf einem Gerät benötigt werden oder über sonstige Mechanismen (z. B. Versionskontrollsystem) zwischen mehreren Geräten synchronisiert werden
• Cloud / Synchronisiert:
  Daten die offline verfügbar sein sollen, aber auf allen Geräten gelesen und oder bearbeitet werden müssen
• NAS / Netzlaufwerk:
  Daten die nur mit Netzwerkverbindung zur Verfügung stehen müssen und Daten die i. d. R. nicht mehr verändert und selten gelesen werden

Einordnung #

Mit dem Speicherplatz der lokalen und der synchronisierte Persistenzebene wird eher sparsam umgegangen. Während Netzlaufwerke eher großzügig genutzt werden. Lokaler Speicher ist nach meiner Erfahrung immer knapp und lässt sich in Notebooks nur begrenzt erweitern oder ist unverhältnismäßig teuer. Cloud-Speicher ist für kleine Datenmengen oft günstig, wird aber für große Datenmengen auch schnell teuer. Netzlaufwerke hingegen bieten den vergleichsweise günstigsten Speicher. Daher werden z. B. Daten für abgeschlossene Aufgaben und Projekte aus dem lokalen und synchronisierten Speicher auf ein Netzlaufwerk verschoben, um Platz für Neues zu schaffen.

Eine Ausnahme bilden Projekte, deren Änderungen mit einem verteilten Versionskontrollsystem verwaltet werden. Sie sind i. d. R. mit ihrer Entwicklungsgeschichte auf einem zentralen Server gespeichert. Deshalb liegen sie im lokalen Speicher und können trotzdem auf mehreren Geräten konsistent bearbeitet werden. Sie können nach Synchronisation mit dem Server auch jederzeit aus dem lokalen Speicher gelöscht werden, um Platz zu schaffen. Eine Kopie auf dem Netzlaufwerk ist für sie höchstens als Backup sinnvoll.

Unveränderliche Ressourcen, die aufgaben- und projektübergreifend genutzt werden, brauchen ebenfalls nicht im synchronisierten Speicher abgelegt werden. Auf dem Netzlaufwerk sind sie am besten aufgehoben. Mit Hilfe eines Shell-Skriptes können sie selektiv auf die lokale Persistenzebene kopiert werden, um sie offline verfügbar zu machen. Dort kann man sie jederzeit löschen, wenn sie für die aktuelle Arbeit nicht (mehr) benötigt werden.

Wichtig: Die hier beschriebenen Persistenzebenen ersetzen keine Backup-Strategie. Für jede der Persistenzebenen ist ein Backup mindestens empfehlenswert.

Synchronisation #

Zur automatischen Synchronisation von lokalen Daten werden Dienste wie Seafile, DropBox oder ähnliches genutzt. Das Synchronisationsprogramm muss die Synchronisation von ausgewählten Ordnern an einem frei wählbaren Ort im Dateisystem unterstützen.

Netzlaufwerke #

Im einfachsten Fall werden Benutzerdaten auf einem einzigen Netzlaufwerk (Share) abgelegt. Es ist aber auch möglich, die Daten für verschiedene Kontexte auf unterschiedlichen Netzlaufwerken abzulegen. Die Daten die zu einem Kontext gehören werden aber immer auf genau einem Netzlaufwerk gespeichert.

Struktur #

In diesem Abschnitt wird die konkrete Ordnerstruktur in vier Ebenen beschrieben.

Ebene 0 – Wurzel #

Die oberste Ebene der Ordnerstruktur ist das Wurzelverzeichnis. Der Pfad für das Wurzelverzeichnis kann auf verschiedenen Geräten unterschiedlich sein.

Beispiele:

• Benutzerprofil unter Windows: C:\Users\Me\Daten
• Zusätzliche Datenpartition unter Windows: D:\repo
• Benutzerprofil unter Linux: /home/me/repo

Um Programme darüber zu informieren, wo die Wurzel der Ordnerstruktur liegt, wird eine Umgebungsvariable im Benutzerprofil verwendet: REPO

Im Wurzelverzeichnis liegen nur Ordner die einen Kontext repräsentieren oder Ordner die mehrere Kontexte gruppieren (siehe Ebene 1). Es werden keine Dateien im Wurzelverzeichnis abgelegt. Einzige Ausnahme sind Dateien, welche die Verwaltung der Ordnerstruktur als ganzes erleichtern: z. B. eine README-Datei, in der die Ordnerstruktur erläutert wird.

Ebene 1 – Kontext #

Kontexte können ein- oder zweistufig sein. Sie sollten jedoch nicht tiefer als zwei Stufen sein. Kontexte werden in der Alltagssprache benannt und nach Möglichkeit abgekürzt. Die Namen von Kontexten dürfen keine Leerzeichen enthalten.

Typische Beispiele für einen Kontext sind:

• Allgemein
• Arbeit
  • ABC Kürzel für Arbeitgeber
  • XYZ Kürzel für Arbeitgeber
• Freiberuflich
  • ABC Kürzel für Auftraggeber
  • XYZ Kürzel für Auftraggeber
• Privat
• Spielwiese
• Sportklub
• Temp

Um die verschiedenen Persistenzebenen für einen Kontext zu realisieren, werden je Kontext mehrere Ordner bzw. Dateien angelegt. Dabei erhält der Name des Kontexts ggf. ein Suffix:

• Lokal: kein Suffix
• Synchronisiert: .sync
• Netzlaufwerk: .share

Die lokale und die synchronisierte Persistenzebene eines Kontexts werden jeweils durch einen Ordner im Wurzelverzeichnis abgebildet. Im Synchronisierungsprogramm wird der jeweilige Ordner mit dem Suffix .sync als Ziel für die Synchronisation konfiguriert.

Wie das Netzlaufwerk in der Ordnerstruktur abgebildet wird, ist vom Betriebssystem abhängig. Unter Windows kann eine Verknüpfung auf den UNC-Pfad genutzt werden. Das ist halbwegs komfortabel und robust. Alternativ kann das Netzlaufwerk an einen Laufwerksbuchstaben gebunden werden und eine Verknüpfung zeigt auf den entsprechenden Dateisystempfad. Liegt das Wurzelverzeichnis auf einer NTFS-Partition, können Netzlaufwerke auch mit mklink als symbolische Verknüpfung eingebunden werden. Allerdings kommen damit erfahrungsgemäß nicht alle Programme gleichgut zurecht. Unter Linux kann der Kontextordner aus dem Netzwerk direkt auf den Kontextordner mit dem Suffix .share im Wurzelverzeichnis gemountet werden.

Kontextordner enthalten ausschließlich Ordner für Kategorien Ebene 2. Es werden keine Dateien direkt in einem Kontextordner abgelegt. Einzige Ausnahme sind Dateien, die den Kontext selbst beschreiben: z. B. eine README-Datei, in der die Abgrenzung des Kontexts erläutert wird.

Ebene 2 – Kategorie #

In jedem Kontext werden die Daten nach ihrer Kategorie gruppiert.

Die Kategorie wird nach Möglichkeit mit kurzen standardisierten englischen Namen bezeichnet.

Bewährte Kategorien:

• archive
  Daten die klar einem Zeitpunkt zugeordnet sind und nicht mehr verändert werden.
  Es kann hilfreich sein, alle Dateien und Ordner im Archiv mit einem Zeitstempel als Präfix zu versehen. Dies konserviert den Zeitpunkt, dem die Daten zugeordnet werden, explizit und unabhängig von den Metainformationen die das Dateisystem evtl. speichert. Dabei hat sich das ISO-Format für den Zeitstempel bewährt, da es eine chronologische Sortierung erleichtert.
• contract
  Dateien die den Rahmen für einen Kontext beschreiben. Z. B. Arbeitsverträge, Auflagen und sonstige Rahmenbedingungen. Sie sind i. d. R. unveränderlich
• plog
  Persönliches Protokoll zur Dokumentation der Arbeitsschritte und von sonstigen Tätigkeiten.
  Das persönliche Protokoll könnte ein Obsidian-Vault sein oder einfach eine Textdatei pro Tag. Bei mir haben sich zweistufige Unterordner nach Jahr und Monat bewährt: JJJJ/JJJJ-MM/JJJJ-MM-TT.md
• playground
  Gruppen von Dateien und Ordnern zum Ausprobieren von Techniken oder Konzepten. Kann bei Bedarf durch jährliche oder monatliche Unterordner strukturiert werden.
• projects
  Gruppen von Dateien und Ordnern zur Bewältigung von bestimmten länger laufenden Aufgaben (siehe Ebene 3)
• res
  Unveränderliche Dateien, meist aus externen Quellen, die regelmäßig zur Bewältigung von verschiedenen Aufgaben benötigt werden.
  (z. B. Grafiksammlung, Literatur, etc.)
• templates
  Vorlagen für wiederkehrende Aufgaben und regelmäßig zu erstellende Dokumente.
  (z. B. die Formularvorlage für die geliebte Dienstreisekostenabrechnung, oder auch Projektvorlagen)
• tmp
  Kurzfristig benötigte Daten, die direkt nach Vollendung eines Arbeitsschritts wieder gelöscht werden
• workitems
  Daten die zu kleinen Aufgaben gehören, die kein eigenes Projekt rechtfertigen. Enthält ausschließlich Unterordner, benannt mit dem Datum an dem die Aufgabe bzw. die Dateien angefallen sind. Als Datumsformat hat sich das ISO-Format bewährt, da es eine chronologische Sortierung erleichtert.

Ob in dem Ordner für eine Kategorie direkt Dateien abgelegt werden oder Unterordner zur weiteren Gliederung verwendet werden, hängt von der Kategorie und der Dateianzahl ab. So spricht nichts dagegen, Dateien direkt in res oder templates abzulegen. In projects hingegen ist ein Ordner je Projekt erforderlich. Und in workitems sollte für jeden Tag, an dem Daten anfallen, ein eigener Ordner angelegt werden.

Ebene 3 – Projektstruktur #

Auch wenn Projekte sehr unterschiedlich sein können, besitzen viele doch eine ähnliche Struktur was ihre Dateien anbelangt. Insbesondere Projekte in der Wissensarbeit und Softwareentwicklung haben oft eine ähnliche Struktur. Dafür haben sich die folgenden Unterordner bewährt:

• auto
  Projektspezifische Programme zur Automatisierung von Arbeitsschritten im Projekt
• artwork
  Quell- und Ergebnisdateien für ornamentale Grafiken die im Projekt benötigt werden. Z. B. Logo, Rahmen, Hintergründe.
• build
  Projektspezifische Programme zur Umwandlung oder Kompilierung der Quelldaten in das Projektergebnis
• contract
  Projektspezifische Dateien, die den Rahmen für das Projekt beschreiben. Z. B. Werkvertrag, Anforderungsdokumente und sonstiges Rahmenbedingungen.
• docs
  Die Dokumentation des Projekts
• lib
  In Softwareprojekten gebräuchlich, um Programmbibliotheken abzulegen, die nicht aus dem Projekt selbst stammen, aber im Projekt benötigt werden
• out
  Das Projektergebnis, stetig aktualisiert und unveröffentlicht. Wird in Softwareprojekten oft auch bin oder dist genannt.
• public
  Veröffentlichte bzw. weitergegebene Version(en) des Projektergebnisses
• res
  Unveränderliche Daten die nicht aus dem Projekt selbst stammen, aber im Projekt benötigt werden
• src
  Quelldaten die die Grundlage für das Ergebnis des Projektes darstellen und direkt bearbeitet werden
• tmp
  Temporäre Dateien die nur kurzfristig benötigt und nach Vollendung eines Arbeitsschritts wieder gelöscht werden

Die Einordnung von Dateien in diese Struktur erfordert ein wenig Übung und Erfahrung. Sie ist oft projektspezifisch und wird durch den konkreten Arbeitsablauf in einem Projekt beeinflusst.

Wenn z. B. Grafiken oder Illustrationen einen wesentlichen Teil des Projektinhalts ausmachen, sind ihre Quelldateien besser in src aufgehoben als in artwork. Ihre Ergebnisdateien sollten in out abgelegt werden, wenn sie direkter Teil des Projektergebnisses sind; alternativ in src oder tmp, wenn sie nur ein Zwischenergebnis sind, welches wiederum als Quelle in das eigentliche Projektergebnis einfließen.

Es spricht nichts dagegen weitere Unterordner zu verwenden, solange klar ersichtlich ist, in welchen Ordner eine Datei gehört. Dazu dürfen sich die Aufgaben der Unterordner nur möglichst wenig überlappen.

Beispiel #

D:\repo
├─ Allgemein               # Kontext lokal
│   ├─ res                 # Offline-Kopie von Allgemein.share\res
│   └─ templates           # Offline-Kopie von Allgemein.share\templates
├─ Allgemein.share         # Kontext Netzlaufwerk
│  → \\NAS\Tobias\repo\Allgemein
│   ├─ res
│   └─ templates
├─ Arbeit                  # Kontextgruppe
│   ├─ THB                 # Kontext lokal
│   │   ├─ projects
│   │   │   └─ Alpha       # Projekt unter Versionskontrolle
│   │   │       ├─ .git
│   │   │       ├─ src
│   │   │       └─ out
│   │   └─ res             # Offline-Kopie von THB.share
│   ├─ THB.sync            # Kontext synchronisiert
│   │   ├─ contract
│   │   ├─ plog
│   │   ├─ templates
│   │   └─ workitems
│   │       ├─ 2025-12-31
│   │       └─ 2026-09-01
│   └─ THB.share           # Kontext Netzlaufwerk
│      → \\NAS\Tobias\repo\THB
│       ├─ projects
│       │   └─ Alpha
│       └─ res
├─ Privat                  # Kontext lokal
│   └─ projects
│       └─ Beta            # Projekt unter Versionskontrolle
│           ├─ .git
│           ├─ docs
│           ├─ src
│           ├─ out
│           └─ res
├─ Privat.sync             # Kontext synchronisiert
│   └─ archive
│       ├─ 2025-12-31
│       └─ 2026-09-01
└─ Privat.share            # Kontext Netzlaufwerk
   → \\NAS\Tobias\repo\Privat
    └─ res