Für Dateiverzeichnisse (Filesysteme) hat sich eine Baumstruktur etabliert. Wir haben uns daran gewöhnt und für die meisten Zwecke ist das auch eine sinnvolle Strukturierung.
Relativ oft wird man aber mit dem Problem konfrontiert, dass es zwei oder mehr Aspekte gibt, nach denen man seine Dateien oder Unterverzeichnisse gruppieren will. Machen wir es mal abstrakt mit Farbe, Form und Größe.
Dann kann man etwa so etwas haben wie
$MAINDIR/rot $MAINDIR/blau $MAINDIR/gruen $MAINDIR/gelb
und in der nächsten Ebene dann jeweils so etwas wie
$MAINDIR/rot/quadrat $MAINDIR/rot/kreis $MAINDIR/rot/dreieck $MAINDIR/rot/sechseck $MAINDIR/blau/quadrat $MAINDIR/blau/kreis ... $MAINDIR/gelb/dreieck $MAINDIR/gelb/sechseck
und darunter jeweils
.../klein .../mittel .../gross
Aber manchmal möchte man es genau anders haben haben, also zuerst nach Form differenzieren, dann nach Größe und zuletzt nach Farbe.
Und es kann oft sehr unpraktisch sein, wenn Dinge, die eigentlich zusammengehören und die man zusammen bearbeiten will, verstreut über das Verzeichnissystem herumliegen.
Es hilft sicher, dass man sich vorher gut überlegt, wie man seine Verzeichnisstruktur aufbaut, so dass es zumindest in möglichst vielen Situationen einigermaßen passt. Es gibt sicher Möglichkeiten, damit umzugehen. Man könnte zum Beispiel alle sechs Verzeichnisbäume anlegen und via Hardlinks oder Softlinks die Dateien, die man im ersten Verzeichnisbaum richtig eingetragen hat, von den anderen Verzeichnisbäumen jeweils passend verlinken (Softlink) oder dort auch eintragen (Hardlink). Das geht unter Linux und Unix mit deren eigenen Dateisystemen gut, es kann aber eine Herausforderung sein, das konsistent zu halten.
Man kann auch die Daten auf Dateisystemebene irgendwie ablegen, vielleicht sogar in einer der möglichen Strukturierungen, aber den Zugriff über eine Applikation anbieten, die es ermöglicht, so darauf zuzugreifen, als wären sie in einer der anderen fünf Arten strukturiert. Ein typisches Beispiel sind Musikprogramme (Player), die es ermöglichen, die Musikstücke nach Genre, Sänger, und vielen anderen Kriterien zu strukturieren und dann mit diesen Daten darauf zuzugreifen. Es gibt dann typischerweise irgendwo Metadaten, die diese Zusatzinformationen enthalten. Hier hat man noch den Zugriff über das Dateisystem, was sehr praktisch ist, gerade bei Musik, aber die Applikation muss Änderungen erkennen und gegebenenfalls die Metadaten anpassen oder sogar interaktiv abfragen und ergänzen.
Noch weiter geht es, wenn die Datenspeicherung völlig intransparent ist, im Extremfall sogar unter Benutzung sogenannter „Raw-Devices“, und wenn man dann nur noch über so eine Applikation an die Daten herankommt. Im Grunde genommen sind alle Datenbanken in dieser Rubrik angesiedelt, aber auch die Repositories vieler Versionsverwaltungssysteme oder auch Content-Management-Systeme, die natürlich wiederum eine Datenbank verwenden können. Eine Folge davon ist, dass man an diese Daten nur noch mit der Applikation oder deren Hilfsprogrammen herankommt und nicht mehr wirklich auf Dateisystemebene damit arbeiten kann. Eine kleine Anzahl von Datenbankprodukten und das zugehörige Knowhow leistet man sich gerne, denn das braucht man und es lohnt sich. Aber wenn jetzt Software unnötigerweise ihr eigenes Repository-Format statt einer einfachen Dateispeicherung verwendet, kann es schon schwieriger werden, die ganzen Daten im Griff zu behalten.
Das Problem ist also in der Praxis dort, wo es eine große Rolle spielt, häufig irgendwie gelöst. Trotzdem wäre es manchmal schön, wenn die Verzeichnisstruktur nicht wie ein Verzeichnisbaum aufgebaut wäre, sondern zumindst in manchen Teilbäumen wie ein dünn besetzter Hyperquader, wo man nach einer Reihe von Kriterien die passenden Dateien suchen und in einem temporären virtuellen Verzeichnisbaum zugänglich machen könnte. Diese Mehrfachindizierung war übrigens auch in Datenbanken vor etwa 30 Jahren eine Herausforderung, wenn die einzelnen Indizes für sich genommen nicht selektiv genug sind. Man hat wohl das Konzept des Z-Index (oder der Z-Kurve) entwickelt, womit eine Verflechtung von verschiedenen Indizes möglich ist, die für sich genommen nicht selektiv genug sind, um für einen bestimmten Indexwert nur noch eine so kleine Menge von Daten zurückzuliefern, dass eine erschöpfende Suche in diesen Daten unproblematisch wäre.
In der Systemadministration stellt sich diese Frage häufig. In der Linux- und Unix-Welt ist es üblich, größere Applikationen so zu installieren, dass etwa 4-6 Orte im Verzeichnissystem verwendet werden:
- ausführbare Programme in /usr/bin oder /usr/local/bin oder /bin o.ä.
- Bibliotheken und statische Hilfsdaten dazu in /usr/lib oder /usr/local/lib oder /opt. Zum Teil architekturunabhängige statische Hilfsdaten und Bibliothken auch in /usr/share. Oft ist die ganze Applikation unter /opt installiert und es gibt softlinks nach /usr/local/bin
- Man-Seiten unter /usr/man, /usr/local/man, /opt/man o.ä.
- Konfiguration unter /etc
- Variable Daten (z.B. Tablespaces für Datenbanken) unter /var/lib, /var/opt o.ä.
- logs unter /var/log
Das ist das, was sich eigentlich etabliert hat und wie die Software, die mit Linux-Distributionen mitkommt, üblicherweise installiert wird. Man hat so nicht die ganze Applikation zusammen in einem Verzeichnis, aber dafür hat man eine Trennung in statische und dynamische Daten und kann auf Servern viel gezielter Entscheidungen darüber treffen, welche Daten in welches Backup kommen, welche Raid-Konfiguration man verwendet, ob man die Daten lokal oder remote hält, ob man sie mit anderen Servern teilen kann und ob man SSDs einsetzt oder auch wer Schreib- und Leseberechtigungen hat. Diese Fragen wird man eher für alle Daten in /var/lib gleich beantworten als für alle Daten unter /tomcat.
So wird die zweitbeste Vorgehensweise, eben alles, was zu einer Applikation gehört, komplett in einem Unterverzeichnis zu halten, trotz ihrer offensichtlichen Reize, eher selten gewählt. Hier wäre so eine Matrixstruktur für das Dateisystem schön, man könnte also Zeilen für die Applikationen haben und Spalten für die Art der Daten (lib, bin, share, var, log, conf, man,…).
