In der
DB finde ich das auch nicht so toll. Eine
DB ist halt kein Fileserver
ja, genau und wenn das filesystem readwrite sein muss und nicht readonly sein kann, aus welchen Gründen auch immer
und dutzende Clients in Netzwerk da auf die Dateinamen und Attribute zugreifen müssen, weil die da mit dem
Explorer darauf arbeiten, entsteht dadurch schon mal eine Menge reiner I/O traffic und was in vielen Fällen
noch schlimmer ist, ein freundlicher Trojaner deiner Wahl räumt die Inhalte da gerne mal auf, egal auf welchem
der angeschlossenen Systeme das über die Dateifreigabe dann ausgelöst hat. Wenn es so was wie
Filesystemtrigger BeforeUpdate geben würde, könntest du immer noch den alten Inhalt sichern
bevor der überschrieben wird, im Netzwerk war es das dann oft mit dem brauchbaren Inhalt der Datei ...
Ein Trojaner, der sich in der Datenbank anmeldet und dann alles löscht, kenn ich so nicht, falls das doch mal
passiert, nennt man den, der das veranlasst hat, zwar vorne auch Tro aber das Wort geht hinten mit ttel weiter
Weitere Aspekte dafür, so was in der
DB zu machen: Echte Transaktionsfähigkeit, keine echten Limits was die Anzahl
der Records betrifft, beliebige viele zusätzliche Attribute und Foreignkeys, Realtime Hot Backup ohne
Trickersei wären schreibvorgänge weiterlaufen, uvm.
Es muss aber jeder für sich bewerten, in kleinen Datenmengen ist der Mehraufwand gegenüber dem Filesystem
vielleicht doch zu hoch, aber die Vorteile überwiegen bei großen Datenmenge erheblich. Daher gab es das aber auch
ja von mir als Video, basiert auf Praxiserfahrungen ...