Ablage von Bilddateien

[Michael Bergbauer]

On 07-Jun-2001 Alexander Skwar wrote:
> So sprach Michael Bergbauer am Thu, Jun 07, 2001 at 05:31:24PM +0200:
>> keinen Zugriff auf das Filesystem der DB hat, und auch keine andere
>> Zugriffsmöglichkeit auf ein zentrales Filesystem besteht. Die meisten gehen
> 
> Hmm, unter welchen Umständen kann es denn sein, das keine
> Zugriffsmöglichkeit auf eine zentrales Filesystem besteht?  Selbst wenn
> Datenbankserver und anderer Server 2 getrennte Rechner sind, so kann man
> doch immer noch NFS o.ä. nutzen.  Sollte dann NFS nicht immer noch besser
> sein als die Binärdaten aus der DB zu lesen?

Naja, ob NFS (AFAIK UDP) besser ist als eine DB-Verbindung über TCP sei jetzt
mal dahingestellt. 

Wovon ich zumindest in diesen Überlegungen ausging, ist eine DB-Anwendung mit
speziell erstelltem CLient, also ohne Benutzung von PHP, CF, ASP, Perl oder so
zu Erstellung von HTML-Seiten, sondern unmittelbarer Zugriff auf die DB. Wenn du
dann aus der DB nur die Pfade zu den Dateien liest und die Daten über NFS,
Windows Shares oä. liest, dann hast du entweder 
a) einen zweiten Satz an Benutzerrechten zu pflegen oder
b) ein Sicherheitsproblem (hat man u.U. auch bei den "normalen"
Webserver-Lösungen, wenn man nicht aufpasst)

Zusätzlich muss man weitere Server/Daemons konfigurieren, das Gesamtsystem wird
dadurch prinzipiell mal anfälliger (zusätzliche Komponenten, die ausfallen
können). Dazu kommt, das man je nach Netzwerkstruktur zusätzliche Löcher in den
Firewalls braucht, evtl. zusätzliche Proxys oä. Wenn man dann mit mehreren
Servern arbeitet, kriegt man auch leicht Probleme mit der Datenkonsistenz. Wenn
man dann stattdessen nur ein System hat, das es zu betreuen gilt, sinken
mögliche Problem- bzw. Fehlerquellen. 

Da gerade bei Projekten, in denen man die Zeit und Geld hat, eigene,
massgeschneiderte DB-Clients zu entwickeln, auch bei der Kohle für die Server
nicht unbedingt um Tausend oder Zehntausend DM gefeilscht wird, ist es dann
u.U. sinnvoller, alles in die Datenbank zu werfen (wobei ich dann allerdings
auch nicht mehr unbedingt zu MySQL tendieren würde, Kosten für eine oder
mehrere Oracle-Lizenz(en) spielen allerdings dann eigentlich auch nur noch eine
untergeordnete Rolle.

Ums mal konkret zu machen (ohne jetzt allerdings auch Daten aus meiner Praxis
zu verwenden da ich in dem Umfeld nicht tätig bin): Lagerverwaltung in einem
grösseren Konzern, zusätzlich zu den reinen Lagerdaten (Teile, Anzahl,
Lieferant, Preis, usw) sind auch noch - je nach Bauteil technische Daten,
Prüfberichte zu einzelnen Chargen usw. in der DB gespeichert, evtl auch
Lieferverträge, Einkaufskonditionen; da nun nicht jeder Mitarbeiter Zugriff auf
alle Daten haben muss und auch nicht braucht, und für die Datenbank an und für
sich sowieso schon eine Rechteverwaltung existiert, macht es doch wenig Sinn,
die Dokumente auf nen Fileserver zu legen, dort u.U. mit einem schlechteren
Rechtesystem zu arbeiten (berauschend sind die Möglichkeiten unter Unix
z.B. nicht gerade, auch wenn man ne Menge damit machen kann), und ich das
Problem hab, das jemand mit entsprechendem Wissen die Rechte auf dem Fileserver
ändern kann, und damit vielleicht das ganze Sicherheitssystem aushebeln kann,
weil er eben auch ohne meinen Client auf die NFS-Freigabe zugreigen kann, dann
stell ich mir doch nen eine Nummer grösseren Server hin, und pack alles in
meine DB.

Was ich eigentlich sagen wollte: Die hier immer wieder getätigte Aussage
"Bilder in der DB sind nicht sinnvoll" mag für 99% der Fälle richtig sein, und
wenn jemand nach dem ersten Hinweis auf diese Regel darauf besteht, seine
Bilder doch reinpacken zu wollen, dann lasst ihm doch diesen Willen. Erstens
ist es möglicherweise sein Problem und nicht eueres, und er kennt seine
Anforderungen und zur Verfügung stehende Resourcen besser. 

Michael

-- 
Michael Bergbauer <michael.bergbauer_(at)_gmx.net>
Use your idle CPU cycles.
See http://www.distributed.net and win $ 1 000.
Visit our mud Geas at geas.franken.de Port 3333

---
!!NEU!!
Fragen und Antworten zu MySQL und dieser Liste unter
-->>  http://www.4t2.com/mysql