nicht angemeldet
Moin!
das würde ich so nicht sagen. wenn man mal in die geschichte ein wenig zurück geht, dann waren textdateien vor den dbms system da. und die gründe warum man dbms systeme entwickelt hat, waren in der hauptsache die dynamik oder auch datenunabhängigkeit genannt und nicht viele, kleine datenmengen zu verwalten.
Wenn du historisch argumentieren willst, mußt du berücksichtigen, was damals für Hardware, Speichermengen und Performance zur Verfügung stand. Ich würde nicht historisch argumentieren wollen, denn was interessieren für die heutigen Anwendungen mit heutiger Hardware die Probleme von damals?
der große unterschied zwischen textfiles und dbms besteht darin, dass ein programm, welches auf die text-datei zugreift eine statische optimierung ist, sprich struktur, anzahl, inhalt der daten und vor allem die anzahl der unterschiedlichen programme, welche aud den daten operieren sollten sich nicht verändern, ansonsten kann das zum teil sehr grosse probleme bereiten. firmen hatten damit sehr stark zu kämpfen, die dynamik der geschäftswelt in der DV abzubilden. es war einfach viel zu umständlich mit einem textfile. und deswegen findet man heute auch in der datenverarbeitung auch in aller regel keine textdateien mehr. nicht weil es funktional nicht geht, sondern weil man sich damit zu stark an eine struktur bindet. deswegen hat man überhaupt erst dbms entwickelt.
Und was ist mit XML? Das sind im Prinzip doch auch "nur Textdateien", aber der Dateiinhalt dürfte mit zum flexibelsten zählen, was man heutzutage auffinden kann.
Dein Ansatz mit Dynamik geht meines Erachtens fehl. Datenbanken haben gegenüber simplen Textdateien EINEN wichtigen Vorteil, und das ist das standardisierte Interface für den Zugriff.
Spätestens seit der Erfindung von XML ist das aber nicht mehr Alleinstellungsmerkmal von Datenbanken.
letztlich ist es auch nur eine software, die aber bezüglich der dynamik optimiert wurde. bei einem dbms kann man sehr leicht die dynamischen prozesse abbilden und anpasen, was man über eine textdatei nicht kann.
Eine Datei ist mit das dynamischste, was ich mir vorstellen kann. Man kann beliebig viele, beliebig gewählte Bytes dort reinspeichern. Bei einer Datenbank muß man sich aber immer an die Definition der Spalten halten.
Abgesehen davon glaube ich nicht, dass eine Datenbank wirklich dynamische Prozesse abbilden kann. Dafür ist sie nicht vorgesehen. Die dynamischen Prozesse sind Aufgabe des (oder der) Layers VOR der Datenbank.
meiner meinung steht deswegen nicht im vordergrund, welche art von daten ich habe, sondern vielmehr die dynamik. die frage ist, kann ich garantieren, dass sie die art der daten auch in der zukunft nicht verändern werden. und da nur wenige menschen über die gabe verfügen, in die zukunft schauen zu können, würde ich im zweifelsfall immer ein dbms benutzen.
Diese Argumentation halte ich für unsinnig. Wie soll denn eine Datenbank besser helfen können, wenn sich die Datenstrukturen verändern, als eine Datei. In beiden Fällen ist die abfragende Software so zu modifizieren, dass sie mit den geänderten Verhältnissen wieder zurecht kommt - aber um diese Veränderung wird man nicht herumkommen. Die Datenbank bietet da nach meiner Auffassung keine substantiellen Vorteile, die man nicht auch mit Dateien haben könnte.
auch hackt dein beispiel mit den bildern ein wenig. sicherlich sieht es auf den ersten blick leichter aus, auf die bilder via html zuzugreifen. aber die verwaltung der daten ausserhalb einer datenbank ist wesentlich aufwendiger.
Du argumentiert aus Sicht eines einfachen Anwendungsprogrammierers. Natürlich ist es für den aufwendiger, wenn er erst ein Dateihandling erstellen muß, um die Bilder nicht in die Datenbank packen zu müssen - würde er einfach das BLOB füllen und später wieder auslesen, wäre alles in Butter.
Das bedeutet doch aber nicht, dass dieser Aufwand trotzdem anfällt. Er wird nur versteckt, nämlich hinter den Kulissen der Datenbank.
das mag bei einer überschaubaren anzahl noch gehen. aber wenn die bilderanzahl wächst und vor allem unterschiedliche personen unterschiedliche bilder gehören, dann wird es schwieriger.
Wenn die Verhältnisse in dem Gesamtsystem einigermaßen gesittet sind, dann muß man nicht befürchten, dass ein in der DB referenziertes Bild unerwartet verloren geht (dafür sind im Zweifel Backups zuständig), und genauso kann man jederzeit ermitteln, welche existierenden Bilder überflüssig sind - sofern jemand vergißt, die beim Löschen der Referenz gleich mit zu löschen (wovon ich nicht ausgehe, ansonsten ist das ein Programmfehler).
auch muss ich eventuelle rechte berücksichttigen, damit nicht jeder über die URL die bilder ansieht, die er nicht sehen soll.
Das muß man nur, wenn tatsächlich Zugriffsrechte eingeschränkt werden sollen, sonst nicht.
Aber auch in so einem Fall würde ich es durchaus als performanter einschrätzen, wenn man Bilder einfach direkt aus der Datei an den Browser sendet, als erst eine Datenbank bemühen zu müssen.
wird zum beispiel eine person aus der datenbank gelöscht, dann muss ich auch seperat dafür sorgen, dass die bilder mitgelöscht werden. ein dbms kann dass ganz bequem über die referientielle integrität sicher stellen.
Schon mal mit MySQL gearbeitet? Da ist "referentielle Integrität" ein Fremdwort, du bist als Programmierer vollkommen selbst dafür verantwortlich, dass alle Datensätze in verlinkten Tabellen verschwinden, wenn du den Master-Datensatz löschst.
Referentielle Integrität kostet dich immer Performance.
der mehraufwand immer über ein dbms auf die daten zuzugreifen, also den direkten weg nicht zuzulassen ist wesentlich kleiner, ja sogar fast zu vernachlässigen, als die probleme die mir die verwaltung und die statik von textdateien bereitet. diese art von problemen sind nämlich in der vergangenheit bei den firmen in die millionen gegangen und haben schnelle dynamische entwicklungen verhindert.
Wir können ja gerne mal den Test machen: Tausend Bilder sind einmal auf einem HTTP-Webserver im Dateisystem abgelegt, und einmal im BLOB in der Datenbank. Keine Rechtekontrolle, die Bilder sind alle öffentlich.
Welche Version wird wohl die meisten Bilder pro Sekunde ausliefern können?
Ich hoffe, du gibst zu, dass die Problemlösung immer etwas mit dem Problem zu tun hat. Der Apache-Webserver ist ganz grob darauf optimiert, statische Dateien recht schnell ins Netz zu übertragen. Andere Webserver sind sogar explizit NUR auf diese Aufgabe hin optimiert (unter Linux beispielsweise khttpd, der "Kernel-Webserver"). Wenn die Aufgabe also lautet: "Puste mir die Bilder so schnell es geht ins Web", dann verbietet sich eine Datenbank einfach von selbst.
Wenn es umgekehrt zuallererst darum geht, die referentielle Integrität sicherzustellen, dann bietet sich die Speicherung im BLOB sicherlich an, ist aber mit Sicherheit auch nicht so performant.
- Sven Rautenberg