Mailinglisten-Archive |
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
php::bar PHP Wiki - Listenarchive