{"id":876,"date":"2008-01-16T21:35:18","date_gmt":"2008-01-16T20:35:18","guid":{"rendered":"http:\/\/www.glorf.it\/blog\/2008\/01\/16\/sql-server\/sollen-bilder-in-die-datenbank"},"modified":"2008-01-16T21:37:34","modified_gmt":"2008-01-16T20:37:34","slug":"sollen-bilder-in-die-datenbank","status":"publish","type":"post","link":"http:\/\/www.glorf.it\/blog\/2008\/01\/16\/sql-talk\/sql-server\/sollen-bilder-in-die-datenbank","title":{"rendered":"Sollen Bilder in die Datenbank?"},"content":{"rendered":"

Jan stellte in seinem Kommentar<\/a> eine sehr gute Frage, die ich hier beantworten möchte:<\/p>\n

Dann habe ich gleich mal eine Frage an den Profi: Ab wann \/bis wann ist es sinnvoll und praktikabel eine Datei in einer Datenbank zu speichern und nicht nur den Pfad der Datei im dazugehörigen Filesystem (Ist es das überhaupt?). Die Last der Datenbank ist ja um ein vielfaches höher als wenn zusätzlich über das Filesystem gelesen und geschrieben wird. Gehen wir mal von eine Fotodatenbank mit vlt. 5000 Bildern \u00e0 2MB aus, das sind wir ganz schnell bei knapp 10GB die über die DB verwaltet werden müssen (OK, große Datenmengen sollten nicht das Problem sein, nur fehlt mir da die Erfahrung.). Kennst du dazu vlt. ein paar hilfreiche Quelle bzw. eine anständige Kosten-Nutzen-Analyse?<\/p><\/blockquote>\n

Zunächst muss man mal sehen, in welchem Bussiness-Sektor<\/strong> wir uns bewegen.<\/p>\n

Im privaten Bereich<\/b> wird man vermutlich die Daten auf der Festplatte des PCs speichern (unter Windows XP oder Vista) oder ein Windows XP\/Vista als Peer-Server nutzen. Dann hat man vermultich die "billige" SQL-Server-Express-Edition im Einsatz. Sie kann maximal 4 GBytes große Datenbanken bearbeiten. Dann ist Schluss und man müsste zu der nächst-höheren Standard-Edition greifen. Deswegen kommt es hier<\/em> meines Erachten aus Kostengründen<\/em> nicht in Frage die Bilder in die DB zu packen. <\/p>\n

Sind wir im professionellen Bereich<\/strong>, dann läuft vermutlich eine SQL-Server-Standard-Edition auf einem Windows-Server-System. Hier gibt es keine Größenbeschränkung. <\/p>\n

Performance und Ausfallsicherheit:<\/strong><\/p>\n

Meiner Erfahrung nach machen SQL-Datenbanken auf IDE<\/a>- und SATA<\/a>-Festplatten leichter mal schlapp als auf RAID-Systemen. Meist ist auf den PCs nämlich der Schreibcache der Festplatten bzw. deren Controllern aktiviert. Kommt es dann während eines Schreibvorgangs zu einem Stromausfall oder einem harten Reset, kann die Datenbank schon mal kaputt sein. Dann ist man unter Umständen schlecht bedient, wenn man Bilder in einer Datenbank hat. Wer hat schon eine tagesaktuelle Sicherung parat oder ist Experte in Sachen Datenbank-Reparatur?<\/p>\n

Schaltet man den bösen Schreib-Cache aus, dann spürt man das in der Performance meistens sehr deutlich, wenn der SQL-Server das nicht mit einem großen Daten-Cache etwas ausgleichen kann. Mit der Express-Edition ist der Cache auf maximal 1 GBytes beschränkt.<\/p>\n

Am Server gilt das nicht so stark: hier werden (hoffentlich) schnelle RAID-Systeme<\/a> eingesetzt, die meist noch mit der USV <\/a>(unterbrechungsfreien Stromversorgung) abgesichert sind.<\/p>\n

Verblüffenderweise ist die Performance in beiden Fällen nicht so gravierend anders als seien die Bilder direkt auf der Platte abgelegt. Je nach API (.Net bekommt im Punkto Laufzeit hier einen Malus) reden wir von 20 bis 50% "Aufpreis". Das klingt nach viel, ich hätte aber durchaus mehr befürchtet.<\/p>\n

Handhabung<\/strong><\/p>\n

Als wichtigestes Kriterium würde ich aber heranziehen, wie mit den Bildern gearbeitet werden soll. Wenn man beispielsweise mit einem beliebigen Programm darauf zugreifen will, dann muss man tief in die Trickkiste greifen, wenn sie in einer Datenbank liegen. Im Normalfall kann man weder im Explorer, noch im Bildverarbeitungsprogramm die Bilder sehen, bearbeiten oder speichern, die in einer Datenbank liegen. Ich nutze beispielsweise gelegentlich eine Software, die doppelte Bilder erkennt und dann löscht.
\nWill man das mit seiner Anwendung erreichen, dann muss man sich in den Explorer "einklinken" und die Bilder so anzeigen als seien sie in einem Dateisystem. Das habe ich noch nicht gemacht und halte es deswegen für nicht so einfach. Gute Dokumenten-Management-Systeme können das aber.
\nWahrscheinlich ist es sau schwer, sonst sähe man das öfter… \ud83d\ude09<\/p>\n

Aus Gründen der Handhabung würde ich die privaten Bilder deswegen gar nicht in der Datenbank speichern.<\/p>\n

Weiterführende Quellen (oder eine Kosten-Nutzen-Analyse) fallen mir gerade nicht ein. Meist wird nur thematisiert wie man Bilder als BOLBs schreibt oder liest. Falls ich noch etwas finde, dann schiebe ich den Link nach.<\/p>\n

Alles neu macht der Mai:<\/strong><\/p>\n

Ab dem SQL-Server-2008 wendet sich übrigens das Blatt. Der kennt als neuen Datentyp FileStreams<\/a>. Da liegen die Dateien "normal" auf der Platte, die Daten werden vom SQL-Server aber mit verwaltet als seien es seine eigenen. Ich denke, dass ist das Vermächtnis des WinFS<\/a>.
\nJetzt müssen wir noch die Daumen halten, dass dies Feature wegen zu vieler Fehler nicht aus der Liste purzelt, sondern wirklich in der Freigabeversion drin ist… \ud83d\ude09<\/p>\n","protected":false},"excerpt":{"rendered":"

Jan stellte in seinem Kommentar eine sehr gute Frage, die ich hier beantworten möchte: Dann habe ich gleich mal eine Frage an den Profi: Ab wann \/bis wann ist es sinnvoll und praktikabel eine Datei in einer Datenbank zu speichern und nicht nur den Pfad der Datei im dazugehörigen Filesystem (Ist es das überhaupt?). Die […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[16],"tags":[],"_links":{"self":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/876"}],"collection":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/comments?post=876"}],"version-history":[{"count":0,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/876\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/media?parent=876"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/categories?post=876"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/tags?post=876"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}