Was bringt eine Datenbank?

[Lutz Fechner]

HI!
Dumme Frage wahrscheinlich ja, aber was bringt eine Datenbank im Vergleich zu einer Textdatei auf dem Server für Vorteile? Ich mein eine Datenbank speichert Daten ab, klar, und nicht irgendwie sondern die Daten hängen natürlich logisch zusammen, aber das kann man doch per txt-file auch alles realisieren, und schwer isses nich.
Vielelicht kann mich mal jemand mit einer wahrschienlich SEHR kurzen antwort aufklären?
P.S. (unnötiges Kommentar) Ich bin ziemlicher PHP-Anfänger ;) (wer das immer noch nich gemerkt hat)

[unbekannter typ]

Hi,

stell dir vor, du hast einen online shop und willst eine produktsuche realisieren. in der datenbank hast du einen sql befehl und kannst genau die datensätez fragen. stehen die daten in ner txt datei, ist dies wesentlichj komplizierter und dauert länger.

datenbanken sind wesentlich einfacher, dynamischer, leichter zu erweitern, ...

ich wollte früher auch nie eine nutzen, danach wurde ich süchtig.

einfach nur geil. probiers aus.
unbekannt

HI!
Dumme Frage wahrscheinlich ja, aber was bringt eine Datenbank im Vergleich zu einer Textdatei auf dem Server für Vorteile? Ich mein eine Datenbank speichert Daten ab, klar, und nicht irgendwie sondern die Daten hängen natürlich logisch zusammen, aber das kann man doch per txt-file auch alles realisieren, und schwer isses nich.
Vielelicht kann mich mal jemand mit einer wahrschienlich SEHR kurzen antwort aufklären?
P.S. (unnötiges Kommentar) Ich bin ziemlicher PHP-Anfänger ;) (wer das immer noch nich gemerkt hat)

[Dark Sider]

Hi,

in der datenbank hast du einen sql befehl

Ne, ganz und überhaupt nicht.
In einer Datenbank habe ich Daten, keine Befehle.

datenbanken sind wesentlich einfacher, dynamischer, leichter zu >>erweitern, ...

Das kommt auf den Zweck der Nutzung an; komplexe Daten würd ich auch in einer DB ablegen, aber für "einfache" Dinge genügt IMHO ein Textfile.

MfG

Dark Sider

[unbekannter typ]

Hi,

hatte mich wohl etwas unglücklich ausgedrückt.

noch ne sache, was in einer text datenbank nicht geht. in einer mysql datenbank kannst du auch bilder reinhauen. ist aber nicht zu empfehlen.

enjoy

[Christian Kruse]

Hallo unbekannter,

noch ne sache, was in einer text datenbank nicht geht. in einer
mysql datenbank kannst du auch bilder reinhauen.

Warum sollte das in Text-Dateien nicht gehen? Dir ist klar, dass
Datenbanken die Daten auch nur in Dateien speichern?

Grüße,
 CK

[Dark Sider]

Hi,

hatte mich wohl etwas unglücklich ausgedrückt

nein, du verwechselst DATENBANK mit TEXTFILE.

noch ne sache, was in einer text datenbank nicht geht

s.o.

Und ich brauche keine mysql-Datenbank, um Texte oder Bilder zu speichern.
Das kann ich auch mit Oracle haben. (Und da hab ich bei der Realisierung mehrerer ContentManagementSysteme keinerlei Probleme gehabt, Bilder zu speichern)

MfG

Dark Sider

[Rolf Rost]

hi,

noch ne sache, was in einer text datenbank nicht geht. in einer mysql datenbank kannst du auch bilder reinhauen. ist aber nicht zu empfehlen.

Wer sagtn das, dass das nicht zu empfehlen ist !!!???

Also, (verhärtete)Fronten mal aufgeweicht und zugehört:

Wenn ich ne DB verwende - dann auch konsequent!

Hab gelesen, dass Dateien, in DBs gespeichert, diese 'aufblähen'

Ja und!? Das machen alle Daten!!

Ach ja, ich war viele Jahre im Schaltungsentwurf - da gab es auch einen schönen Satz damals (1981 - 1983): 'Theroretisch ist es machbar, praktisch nicht'. Kommt mir heute immer noch seeehr bekannt vor, und das sowohl hinsichtlich verfügbarer Soft~ als auch Hardware.

Gruss, Rolf

[wahsaga]

hi,

noch ne sache, was in einer text datenbank nicht geht. in einer mysql datenbank kannst du auch bilder reinhauen. ist aber nicht zu empfehlen.

Wer sagtn das, dass das nicht zu empfehlen ist !!!???
Also, (verhärtete)Fronten mal aufgeweicht und zugehört:
Wenn ich ne DB verwende - dann auch konsequent!
Hab gelesen, dass Dateien, in DBs gespeichert, diese 'aufblähen'
Ja und!? Das machen alle Daten!!

skateboards (= datenbank) sind klein und flink, bringen dich schnell da hin, wo du hinwillst.

wenn du aber einen großen kühlschrank durch die halbe stadt transportieren willst, machst du das besser nicht, in dem du ihn auf skateboards stellst, sondern du hievst ihn besser auf die ladefläche eines kleinlasters (= datei-system) - der ist zwar nicht so klein und wendig, aber für diese aufgabe trotzdem besser geeignet.

gruß,
wahsaga

[Rolf Rost]

hi wahsaga,

skateboards (= datenbank) sind klein und flink, bringen dich schnell da hin, wo du hinwillst.

wenn du aber einen großen kühlschrank durch die halbe stadt transportieren willst, machst du das besser nicht, in dem du ihn auf skateboards stellst, sondern du hievst ihn besser auf die ladefläche eines kleinlasters (= datei-system) - der ist zwar nicht so klein und wendig, aber für diese aufgabe trotzdem besser geeignet.

Das ist ja alles schön und gut.

Aber: Wie bringe ich dem skateboard bei wie es mit dem kleinlaster zu reden hat!? Umgekehrt?

Jabbadabbado! Es braucht einen translater. Und der will nicht nur was zu Fressen haben sondern auch zu Trinken (tschuldige den Ausdruck). Und außerdem ist der au noch soo träge, dasser für jedes Wort eine Stunde braucht. Da frage ich mich: brauche ich den!?

Nooiii! I seh zu dass I ein Skateboard kriege was mir den Kühlschrank lupft - kein Thema, finde ich bei den Inkas...

;-)

Gruss, Rolf

[Christian Kruse]

Hallo Rolf,

Jabbadabbado! Es braucht einen translater. Und der will nicht nur
was zu Fressen haben sondern auch zu Trinken (tschuldige den
Ausdruck). Und außerdem ist der au noch soo träge, dasser für jedes
Wort eine Stunde braucht. Da frage ich mich: brauche ich den!?

Du glaubst aber nicht ernsthaft, dass HD-Zugriffe langsamer seien
als Datenbank-Zugriffe? Denn das lese ich aus deinem Posting. Ich
hoffe, dir ist klar, dass das Gegenteil der Fall ist.

Grüße,
 CK

[Rolf Rost]

Hallo Rolf,

Jabbadabbado! Es braucht einen translater. Und der will nicht nur
was zu Fressen haben sondern auch zu Trinken (tschuldige den
Ausdruck). Und außerdem ist der au noch soo träge, dasser für jedes
Wort eine Stunde braucht. Da frage ich mich: brauche ich den!?

Du glaubst aber nicht ernsthaft, dass HD-Zugriffe langsamer seien
als Datenbank-Zugriffe? Denn das lese ich aus deinem Posting. Ich
hoffe, dir ist klar, dass das Gegenteil der Fall ist.

Sischr, Christian.

Aber so richtig lange müssen die warten, die erst ein RDBMS nach einem Link nach einer Datei fragen die bei IO - Adressierung direkt erreichbar wäre.

--Rolf

[Christian Kruse]

Hallo Rolf,

Du glaubst aber nicht ernsthaft, dass HD-Zugriffe langsamer seien
als Datenbank-Zugriffe? Denn das lese ich aus deinem Posting. Ich
hoffe, dir ist klar, dass das Gegenteil der Fall ist.

Sischr, Christian.

Aber so richtig lange müssen die warten, die erst ein RDBMS nach
einem Link nach einer Datei fragen die bei IO - Adressierung direkt
erreichbar wäre.

Wenn du dich da mal nicht vertust. Die Daten der Datei muessen
aufbereitet und dann erstmal durch den Socket geschoben werden, was
wesentlich aufwendiger ist, als sie einfach auszulesen. Eine
DB-Transaktion ist _sehr_ teuer.

Grüße,
 CK

[Mathias Bigge]

Hi Christian,

neulich traf ich einen Freund in ner Postergalerie, der forsch zu mir meinte: "Wenn Du'n Bild brauchst, mal Dir doch selber eins!"

DB-Transaktion ist _sehr_ teuer.

Nicht das Du am Ende erstmal nen DBMS für die Visitenkartenanwendung schreibst!

Viele Grüße
Mathias Bigge

[Ilja]

yo,

...Eine DB-Transaktion ist _sehr_ teuer...

das kann man so pauschal nicht sagen. letztlich greif ich bei beiden methoden über eine programm auf die daten zu. und will ich vorteile wie indizierung, mehr-user betrieb und viele andere funktionen nutzen, so muss ich sie auch in beiden programmen implementieren. so kann zum beispiel ein dbms daten über das normale betriebssystem und festplatten caching hinaus im speicher halten. und dann wäre die geschwindikeit des dbms wesentlich schneller.

ich würde das für und wieder einer datenbank anders angehen. die frage ist für mich, habe ich ein geeignetes dbms, kann ich es bedienen und funktioniert der betrieb damit für meine zwecke reibungslos. wenn ich diese drei punkte mit ja beantworten kann, würde ich kein textfile nehmen. zwar funktioniert beides in der gegenwart aber:

a) muss ich viele funktionen nicht erst mühsam selber programmieren
b) vielen personen kennen sich mit der funktionalität von dbms aus.
c) bietet ein dbms viele vorteile, die ich mit direkten zugriff nicht erreichen kann, wie zum beispiel datenunabhängigkeit und somit vor allem eines, zukunftssicherheit.

egal ob nun verschiedene programme auf die gleichen daten zugreifen und egal ob ich die datenstruktur in der zukunft ändern will, ich kann mir sicher sein, dass das mit einem dbms sehr einfach und mit wenig aufwand funktioniert. meiner meinung nach ist der hauptvorteil einer datenbank gegenüber eines textfiles nicht, ob es geht oder nicht oder wer in welchen fall schneller ist, sondern vielmehr die zukunftssicherheit. und genau das ist auch der grund, warum überhaupt dbms entwickelt wurden.

Ilja

[Rolf Rost]

Aber Christian,

wesentlich aufwendiger ist, als sie einfach auszulesen. Eine
DB-Transaktion ist _sehr_ teuer.

Um es mal wieder auf das Thema zu bringen...

Wenn ich 10 Kilobyte Text in einem Record zu stehen habe, warum um alles in der Welt sollte ich dann weitere 10 KB NICHT in einen Record schreiben, nur weil diese 10 KB als 'Datei' anstehen!?

Dafür gibt es doch die BLOB Felder. Entwickler von RDBMS hahm die doch nicht dafür gemacht, dass die ignoriert werden.

Und überhaupt: Von einer richtig guten DB Engine erwarte ich dass die ihren Zugriff auf das Filesystem optimiert hat, sprich: gepuffert (Cache) und anderweitig optimiert hinsichtlich Performanze.

Gruss, Rolf

[Sven Rautenberg]

Moin!

Wenn ich 10 Kilobyte Text in einem Record zu stehen habe, warum um alles in der Welt sollte ich dann weitere 10 KB NICHT in einen Record schreiben, nur weil diese 10 KB als 'Datei' anstehen!?

Wozu gehören die 10 KB Text? Wenn das der erste Datensatz ist, und die zweiten 10 KB der zweite Datensatz, dann sollte man sich fragen, warum dafür eine Datenbank notwendig ist.

Wenn die 10 KB aber 1000 Datensätze sind, und für jeden Datensatz einzeln noch mal 10 KB Text dazukommen, dann würde die Datenbank plötzlich 10 Megabyte groß sein. Die 10 KB vorher waren problemlos in einem Puffer zu halten und schnell im Zugriff - die 10 MB sind es eher nicht.

Und natürlich kommt es auch auf die Art des Zugriffs an. Ich halte es nach wie vor für unsinnig, beispielsweise Bilder in der Datenbank zu speichern, sofern man beabsichtigt, diese Bilder via HTTP im Browser anzuzeigen. Denn da entstünde unnötiger Zusatzaufwand.

Extra abgelegte Dateien können direkt vom Server ausgeliefert werden. Für den Zugriff auf die Datenbank aber muß erst ein Programm gestartet werden, zur DB verbinden, ein SELECT ausführen (welcher sich in die durch andere Prozesse stattfindenden Zugriffe auf die DB einordnen muß - und unter Umständen auch mal abzuwarten hat, bis ein Write-Lock wieder aufgehoben wird etc.), die Binärdaten auslesen und an den Browser weitersenden.

Dafür gibt es doch die BLOB Felder. Entwickler von RDBMS hahm die doch nicht dafür gemacht, dass die ignoriert werden.

Doch. :)

Ein BLOB ist ja auch nur ein TEXT - mit dem Unterschied, dass darin case-sensitiv gesucht wird.

Und überhaupt: Von einer richtig guten DB Engine erwarte ich dass die ihren Zugriff auf das Filesystem optimiert hat, sprich: gepuffert (Cache) und anderweitig optimiert hinsichtlich Performanze.

Von einem richtig guten Dateisystem erwarte ich, dass es den Zugriff auf Dateien optimiert hat, sprich: Problem- und anforderungsorientierte Pufferung und anderweitige Optimierungen hinsichtlich Performance.

Es ist in meinen Augen einfach so: Dateisysteme sind dazu da, eher wenige, aber sehr große Informationseinheiten zu verwalten - Dateigrößen so ab 64 KB. DatenBANKEN sind dazu da, sehr viele, aber sehr kleine Informationseinheiten zu verwalten: TINYINT, INT, BIGINT, VARCHAR(255), ENUM, SET - das sind alles winzige Datenmengen, die man in einer normalen Datei gar nicht sinnvoll einzeln speichern könnte.

Insofern besteht der Unterschied zwischen einer Datenbank und einem Dateisystem einfach darin, dass die Datenbank die sehr kleinen Informationseinheiten optimiert verwaltet, ein komfortables Framework für den Zugriff bietet und die Daten kapselt - und sie zusammengefaßt im Dateisystem ablegt.

Diese Betrachtungsweise macht aber ganz deutlich, weshalb das Speichern von Dateien in der Datenbank nicht wirklich sinnvoll erscheint: Die Datenbank ist nur ein weiterer Layer zwischen Anwendung und physikalischem Speicher. Es erscheint wenig einleuchtend, warum das dann plötzlich schneller gehen sollte.

- Sven Rautenberg

[Ilja]

yo,

Insofern besteht der Unterschied zwischen einer Datenbank und einem Dateisystem einfach darin, dass die Datenbank die sehr kleinen Informationseinheiten optimiert verwaltet, ein komfortables Framework für den Zugriff bietet und die Daten kapselt - und sie zusammengefaßt im Dateisystem ablegt.

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.

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.

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.

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.

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. 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. auch muss ich eventuelle rechte berücksichttigen, damit nicht jeder über die URL die bilder ansieht, die er nicht sehen soll. 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.

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.

Ilja

[Sven Rautenberg]

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

[Ilja]

yo,

Ich würde nicht historisch argumentieren wollen, denn was interessieren für die heutigen Anwendungen mit heutiger Hardware die Probleme von damals?

ich führe nicht die historie an, weil früher alles besser war, sondern um die gegenwart besser zu verstehen. und stand der dinge ist, das dbms immer noch das mittel sind, um daten auf professioneller ebene zu verwalten und nicht textdateien. ich wollte damit zum ausdruck bringen, dass datenbanken eine weiterentwicklung der datenhaltung gegenüber textdateien sind.

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.

ich bin wirklich kein xml spezialisst, kann dazu also nur wenig sinnvolles sagen. aber wenn mich nicht alles täuscht, dann ist xml mehr darin flexibel, wie man die gleichen daten darstellt und nicht darin, wie man daten verwaltet. letztlich muss sich xml den gleichen problemen stellen, wenn es die gleichen anforderungen wie moderne dbms leisten will. und dbms leisten viel mehr als einfach nur bytes auf den bildschirm zu bringen.

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.

in einer datei oder datenbank ist erst einmal gar keine dynamik drinne. die dynamik kommt erst dadurch, dass alle zugriffe über ein und daselbe dbms passieren. und damit lassen sich sehr wohl die geschäftprozesse abbilden, nicht anderes passiert tag für tag in den firmen. die praxis ist das beste bespiel dafür. ich würde nie auf die idee kommen, daten der firma in einer textdatei abzuspeichern, es sei denn, mein chef verlangt das von mir ausdrücklich. und selbst dann würde ich mir das schriftlich geben lassen. ausnahmen bilden daten, die sich nie ändern, zum beispiel abgelaufene geschäftsjahre. aber aus das nur mit sehr grosser vorsicht.

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.

dann geh in die betriebe und schau es dir an. wir reden hier nicht von fiktiven dingen, sondern von der praxis. dort ändern sich laufend dinge und man kann es über das dbms abbilden.

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.

ich denke mal deiner "fehler" besteht darin, dass du zu sehr auf die datenspeicherung fixiert bist, sprich textdatei oder datenbank. die dynamik kommt aber von keinen von den beiden, sondern von einer gemeinsamen schnittstelle, nämlich das dbms. und genau das ist der springende punkt. jedes system, dass diese dynamik erzeugen will braucht eine gemeinsame schnitttstelle, egal ob man das nun dbms nennt oder nicht. die blosse speicherung der datenbank über textdateien oder einer datenbank ist nicht wichtig, der zugriff über eine einzige schnittstelle ist es.

Du argumentiert aus Sicht eines einfachen Anwendungsprogrammierers.

nein, aus der sicht eines datenbank-administrators. das sollte ich wissen. und was bedeutet einfach ?

Das bedeutet doch aber nicht, dass dieser Aufwand trotzdem anfällt. Er wird nur versteckt, nämlich hinter den Kulissen der Datenbank.

es ist nicht so, dass nur die eine seite vorteile bringt und die andere seite nachteile. wir neigen sehr gerne dazu zu polarisieren. man muss beides abwägen und dabei liegen dir vorteile von datenbanken für mich um ellen vorne.

... sofern jemand vergißt, die beim Löschen der Referenz gleich mit zu löschen (wovon ich nicht ausgehe, ansonsten ist das ein Programmfehler).

ein wesentlicher aspekt der programmierung ist es, dinge für den programmierer so einfach wie möglich zu halten. dem computer würde der 01 maschinencode reichen, uns menschen aber nicht. es wird einfach zu unübersichtlich. viele moderne poragrammiersprachen und regeln (kis) gibt es nur aus einem grund, weil der mensch nun mal "nur" ein mensch ist. natürlich kann ich immer damit argumentieren, wenn ein fehler auftritt, hätte der programmierer darauf achten müssen. aber es ist ganz eindeutig ein vorteil, wenn ich schon im vorfeld dafür sorge, dass ihm eben nicht so viele solcher fehler unterlaufen könnnen. und die referentielle integrität ist genau dafür da und aus keinem anderen grund. und textdateien können genau diesen vorteil nicht leisten.

Das muß man nur, wenn tatsächlich Zugriffsrechte eingeschränkt werden sollen, sonst nicht.

das ist der springe punkt. man kann dies vielleicht für die gegenwart ausschließen, aber kannst du das auch für die zukunft ?

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.

jein. die frage ist, brauche ich diesen performancegewinn überhaupt oder erkaufe ich mir dafür anicht eventuell viel größere nachteile. abwägen ist gefragt, nicht polarisieren.

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.

ich arbeite beruflich mir oracle. nur weil etwas noch nicht entwickelt ist, heisst es nicht, dass es nicht sinnvoll ist.

Referentielle Integrität kostet dich immer Performance.

nochmal abwägen ist trumph. alles kostest etwas. die frage ist, bekomme ich dadurch aber nicht viel mehr, als ich bezahle. gehe ich auf geschwindikeit, zahle ich eventuelle viel mehr, nämlich mit statischen prozessen.

Welche Version wird wohl die meisten Bilder pro Sekunde ausliefern können?

ich behaupte mal, das ist von fall zu fall verschieden. wenn einfach nur alle der reihenfolge nach ausgegeben werden sollen, bist du schneller. wenn aber andere kritereien eine rolle spielen, dann brauchst du ein oftmals ein dbms dafür.

aber wie gesagt, abwägen und nicht nur eine seite sehen. ich greife mal dein beispiel auf und führe es weiter. in der zukunft sollen nun aber zugriffsrechte für die bilder eingeführt werden. und unterschiedliche programme wollen auf die bilder zugreifen und setzten eine andere datenstruktur vorraus. was nun herr Rautenberg ?

Ich hoffe, du gibst zu, dass die Problemlösung immer etwas mit dem Problem zu tun hat.

für hoffnung und kleine wunder ist der liebe gott zuständig und mit dem hatte ich noch nie was am hut ;-)
ich will mal versuchen anderes zu argumentieren und dich bei deiner "leibspeise" zu packen. sicherlich ist für jede situation (problem) eine spezialisierte lösung die schnellste. aber die situation ändert sich halt laufend, sprich die alte lösung ist auf einmal nicht mehr die beste. wenn ich das nun auf die browser übertrage, so bist du der erste der schreit, nur eine schnisstelle, jeder broser sollte den code gleich interpretieren und nicht sein eigenes süppchen kochen. aber genau das willst du aber von der datenhaltung, jder so wie die situation es gerade verlangt. das geht bei den browsern nicht gut und auch nicht bei der datenhaltung.

nur mal so ein gedanke für dich. gerde in der heutigen zeit, wo rechner deutlich schneller geworden sind, spielt performance,  welche du immerzu ins feld führst, nur noch eine kleinere rolle als die dynamik. und selbst dieses argument der perforamce ist sehr strittig, datenbanken können nämlich sehr wohl schneller sein als die datenhaltung in einer textdatei. wie bereits merhfach erwähnt, abwägen ist trumpf, nicht polarisieren

Ilja

[Ilja]

yo,

habe bei den vielen schreiben ein argument vergessen. du reitest immer so auf der performance rum. dann gehe ich von der annahme aus, dass du nur in maschinencode programmierst oder etwa doch nicht, gibt es dan noch andere argumente ?

Ilja

[Ludger Keitlinghaus]

Hi,

Du glaubst aber nicht ernsthaft, dass HD-Zugriffe langsamer seien
als Datenbank-Zugriffe?

Deine an anderer Stelle eingesehene Argumentationsweise lautet in etwa, wie folgt (wenn ich Dich recht zitiere, ansonsten bitte ich um Nachs(r)icht): Datenbank-Zugriff ist immer auch schreibender Speichermediumzugriff und darum ist Datenbank-Zugriff langsamer

M.E. ist das aber zumindest erlaeuterungsbeduerftig.

Gruss,
Ludger

[Helmut]

Hallo,

Du wirst den Unterschied merken wenn es mal viele Daten sind die es zu verwalten gilt. Klar, man muss nicht alles mit einer DB machen, viele Sachen sind aber mit einer DB effizienter zu lösen.

Ich sag mal so, ein Gästebuch kann man schon mal mit Text Dateien machen, aber bei komplexeren Sachen lebt sich es mit einer DB zur Datenhaltung leichter.

Gruß Helmut

[Lutz Fechner]

Danke! Dann wars ja doch nich so "ACH DU DEPP, DAS IS DOCH KLAR!" DAnn bin ich ja beruhigt und mach mein billig-projekt erstmal ohne Datenbank, danke trotzdem, dass ihr diese "VOLLIDIOTEN"-Frage trotzem ernst beantwortet habt, inanderen Foren wird man als Anfänger oft nur verarscht, wenn man nicht gerade eine überkrasse Frage stellt, die nur 3 Leute beantworten können auf der Welt.
DANKE!

[Rolf Rost]

HI!

Dumme Frage wahrscheinlich ja, aber was bringt eine Datenbank im Vergleich zu einer Textdatei auf dem Server für Vorteile? Ich mein

Selbst wenn ich lediglich Daten in tabellarischer Form speichern will nehme ich eine DB, weil:

• in meiner Scriptsprache (PERL) gibt es einfach zu handhabende Schnittstellen (DBI::MySQl, DBI::ODBC...), womit ich mir für den Zugriff auf meine Daten einen Haufen Arbeit spare gegenüber einer Datenhaltung in Textdateien.

Allerdings räume ich Berkeley - Datenbanken und INI - Dateien dabei eine kleine Sonderstellung ein... je nach Anwendungsfall.

Jo. Wenn es darüber hinaus darum geht, Tabellen referentiell miteinander zu verbinden, ist der Fall sowieso klar: RDBMS.

Beispiel: Dokumentenhierarchie

tabelle folder hat als primary key: folder.index (feld index)
tabelle content hat als primary key content.index.id (felder index, id)

wobei:
    in tabelle content ist content.index ein foreign key auf die tabelle folder

Gruss, Rolf

[Christian Kruse]

Hallo Rolf,

• in meiner Scriptsprache (PERL) gibt es einfach zu handhabende
  Schnittstellen (DBI::MySQl, DBI::ODBC...), [...]

Du meinst sicher DBD::mysql und DBD::ODBC

Grüße,
 CK

[Rolf Rost]

hi Christian,

• in meiner Scriptsprache (PERL) gibt es einfach zu handhabende
  Schnittstellen (DBI::MySQl, DBI::ODBC...), [...]

Du meinst sicher DBD::mysql und DBD::ODBC

Abstrakt meinte ich schon DBI::MySQl, DBI::ODBC...

aber Du hast natürlich recht, es muss DBI:: * heiße

<img src="http://www.rolfrost.de/astro/dbi.gif" border="0" alt="">

Gruss, Rolf

[Axel Richter]

Hallo,

Dumme Frage wahrscheinlich ja, aber was bringt eine Datenbank im Vergleich zu einer Textdatei auf dem Server für Vorteile? Ich mein eine Datenbank speichert Daten ab, klar, und nicht irgendwie sondern die Daten hängen natürlich logisch zusammen, aber das kann man doch per txt-file auch alles realisieren, und schwer isses nich.

Doch, ich behaupte, relationale Daten mit flat files verwalten zu wollen, ist _zu_ schwer, eben weil es _dafür_ relationale Datenbanksysteme gibt.

Behauptung:

Ein Gästebuch, in _einer_ Datei verwaltet, ist mit einem flat file möglich, aber ein Shopsystem sollte mit einer Datenbank verwaltet werden.

Begründung:

Shop in _einer_ Datei:

Bestellnummer; Kunde; Bestelldatum; Artikel; Menge_in_St; Preis_je_St
B1; Müller; 2004-08-02; Hose; 1; 45.78
B2; Maier; 2004-08-02; Jacke; 1; 345.87
B2; Maier; 2004-08-02; Hemd; 3; 15.89
B2; Maier; 2004-08-02; Hose; 2; 45.78
B3; Müller; 2004-08-03; Schuhe; 1; 75.98
B3; Müller; 2004-08-03; Strümpfe; 4; 5.98

Problem: Diese Tabelle enthält redundante Daten (Kunde, Bestelldatum, Artikel, Artikelpreis). Sie wird deshalb schnell sehr groß, schlecht zu sortieren und zu durchsuchen.
Lösung: Man nutzt mehrere Dateien.

Datei Kunden:
Kundennummer; Name
K1; Müller
K2; Maier

Datei Artikel:
Artikelnummer; Bezeichnung; Preis
A1; Hose; 45.78
A2; Jacke; 345.87
A3; Hemd; 15.89
A4; Schuhe; 75.99
A5; Strümpfe; 5.98

Datei Bestellungen:
Bestellnummer; Kunde; Bestelldatum
B1; K1; 2004-08-02
B2; K2; 2004-08-02
B3; K1; 2004-08-03

Datei Positionen:
Bestellung; Position; Artikel; Menge
B1; P1; A1; 1
B2; P1; A2; 1
B2; P2; A3; 3
B2; P3; A1; 2
B3; P1; A4; 1
B3; P2; A5; 4

Diese Dateien enthalten nun keine redundanten Daten mehr. Ihre Größe entspricht nur der wirklich notwendigen Datenmenge. Als einzelne Dateien sind sie auch gut beherrschbar. Die Summe der Programmlogik allerdings, welche man erstellen muss, um diese Dateien in Beziehung zu setzen und konsistent zu halten, um Abfragen zu erstellen und zu suchen, um Löschen und Einfügen zu können ... würde am Ende ein eigenes Datenbanksystem erschaffen. Der Vorteil wäre, dass dieses eigene DBMS, weil es speziell nur für diesen einen Shop geschrieben und optimiert wurde, schneller sein kann (nicht muss) als Standard-DBMS, die universell einsetzbar sein müssen.

Wer sich das antun will, oder wer glaubt es besser (schneller) zu können, als die Profi-DBMS-Entwickler, der soll es tun ;-)).

viele Grüße

Axel