ABAKUS

Hallo,

wenn ich Daten sinnvoll sortieren oder durchsuchen möchte ist BLOB natürlich nicht das richtige. Aber welchen Datentyp nehme ich zum Beispiel wenn ich einen komprimierten Textstring abspeichere?

Liebe Grüße,
Daniela

Blob ist für binäre Daten.... wenn du einen text also z.B. per ZIP komprimierst haste binärdaten...

Wenn du Daten sinnvoll sortieren oder durchsuchen möchtest ist MYSQL sowieso nicht das richtige

godzilla hat geschrieben:Wenn du Daten sinnvoll sortieren oder durchsuchen möchtest ist MYSQL sowieso nicht das richtige

Was ist denn das wieder für ne Aussage...

Kannst du das begründen wieso man MySQL zum Beispiel nicht für einen sortier- und durchsuchbaren Veranstaltungskalender einer kleinen Firma nutzen sollte?

Ui, ein Waldkircher, kommst ja aus derselben Ecke.

Also je nach Daten ist MySQL sehr effizient beim Finden der richtigen Ergebnisse. Als Datenstrukturen werden zum Beispiel Hashtabellen und B-Bäume verwendet. Die Zugriffszeiten sind hier mit einer Komplexität von O(log(n)) angegeben. Teilweise sogar O(1). Besser geht es fast nicht. Wenn es sich nun um speziellere Daten handelt, kann man natürlich bessere Lösungen finden, jedoch wird dies wiederum mit einem entsprechenden Aufwand verbunden sein. Schlechte Performance ist meistens die Folge mangelhafter DB-Kenntnisse, falscher Konfigurationen, schlechter Implementierungen und schlechter Hardware. Selten liegt es am DBMS selbst.

Für ein Veranstaltungskalender ist MySQL sicher eine sehr gute Wahl.

Nach dieser müstergültigen Erklärung traut sich godzilla vermutlich nicht mehr gegen MySQL zu argumentieren. Logge, du hast meinen Flamewar kaputt gemacht

Logge hat geschrieben:.... Schlechte Performance ist meistens die Folge mangelhafter DB-Kenntnisse, falscher Konfigurationen, schlechter Implementierungen und schlechter Hardware. Selten liegt es am DBMS selbst.

Oh ja! Möchte gar nicht wissen, wieviel CO2 durch sinnfreie Abfragen pro Sekunde ausgestoßen wird. So wird heiße Luft zu CO2.

Logge hat geschrieben: Für ein Veranstaltungskalender ist MySQL sicher eine sehr gute Wahl.

Für alles andere fragen Sie PostgreSQL oder Ihren Apotheker

Schlechte Performance ist meistens die Folge mangelhafter DB-Kenntnisse, falscher Konfigurationen, schlechter Implementierungen und schlechter Hardware.

Sowas hört man meistens von Leuten die immer nur 08/15 StandardminiSites gebaut haben.

Fakt ist: MYSQL ist ein relationaler Datenspeicher. Genau dafür kann man sie benutzen, genau dafür ist sie gut. Für den grossen Rest kann man MYSQL einfach vergessen.

godzilla hat geschrieben:...

Sowas hört man meistens von Leuten die immer nur 08/15 StandardminiSites gebaut haben.

Fakt ist: MYSQL ist ein relationaler Datenspeicher. Genau dafür kann man sie benutzen, genau dafür ist sie gut. Für den grossen Rest kann man MYSQL einfach vergessen.

Also möchtest Du Äpfel mit Birnen vergleichen oder was?
Schon klar, dass riesige Dokumentenbestände nicht in einer relationalen DB stehen.

godzilla hat geschrieben:Fakt ist: MYSQL ist ein relationaler Datenspeicher. Genau dafür kann man sie benutzen, genau dafür ist sie gut. Für den grossen Rest kann man MYSQL einfach vergessen.

Also, für vollTextsuche lieber eine API zu einem Texteditor

Im Startpost geht es ja um durchsuchen von "großen Texten" die sogar so groß sind das sie komprimiert wurden ....
...
1. komprimierte Texte sind keine Texte = nicht durchsuchbar
2. muß für ein Textfeld erst irgendwie die volltextsuche(index anlegen) extra eingeschaltet werden .... was die größe der Datenbank erheblich vergrößert .... Fazit: schlechte idee

godzilla hat geschrieben:Sowas hört man meistens von Leuten, die immer nur 08/15-Standardminisites gebaut haben. :-?
[…]
Für den grossen Rest kann man MYSQL einfach vergessen.

Auf diese Weise mit dem „großen Rest“ (lies: dem großen Unbekannten) argumentieren meistens nur Leute, die lediglich glauben, Ahnung zu haben, oder aber nicht in der Lage sind, tatsächlich vorhandenes Wissen weiterzugeben - was für den Wert der Äußerung aufs Gleiche hinauskommt.

So ziemlich alles ist für irgendwas nicht zu gebrauchen. Dein Hinweis darauf war … naja.

800XE hat geschrieben:Im Startpost geht es ja um durchsuchen von "großen Texten" die sogar so groß sind das sie komprimiert wurden ....

Falsch, es ging um das Speichern von größeren Texten, die eben NICHT durchsucht werden müssen und eine Komprimierung ohne großen Aufwand also vielleicht sinnvoll wäre.

Danke für die sinnvollen Antworten, also BLOB.

Um eine sinnvolle Antwort zu bekommen, müsste man wissen um was für Daten es sich konkret handelt. Reden wir hier von 500-Wörter-Texten oder gleich 2GB-ASCII-Text. In beiden Fällen gibt es sinnvolle Lösungen. Wenn man sehr große Datenmengen durchsuchen möchte und die Performance eine große Rolle spielt, kann man über eigene Implementierungen nachdenken (Kosten beginnend im hohen 6-stelligen Bereich). Ich denke aber nicht, dass einer der hießigen Diskussionsteilnehmer in diesen Dimensionen arbeitet.

Relationale Datenspeicher haben sich bewährt und ich denke nicht, dass diese in den nächsten Jahren abgelöst werden. Die Ideen von Herrn Codd sind auch heute noch zeitgemäß.

Wer unbedingt Texte im Petabyte-Bereich speichern und durchsuchen möchte, kann sich ja mal Hadoop reinziehen.

Sowas hört man meistens von Leuten die immer nur 08/15 StandardminiSites gebaut haben.

Ich bin zwar vollkommen auf Deiner Seite Logge, aber

Logge hat geschrieben:...Wenn man sehr große Datenmengen durchsuchen möchte und die Performance eine große Rolle spielt, ...
...Wer unbedingt Texte im Petabyte-Bereich speichern und durchsuchen möchte, kann sich ja mal Hadoop reinziehen...

Daniela hat geschrieben:Falsch, es ging um das Speichern von größeren Texten, die eben NICHT durchsucht werden müssen und eine Komprimierung ohne großen Aufwand also vielleicht sinnvoll wäre.

Du hast Recht. Die Ausgangsfrage habe ich nicht wirklich beachtet. Also wenn man sich Gedanken zum Thema Komprimierung macht, sollte man einige Dinge beachten. Wie viel Speicherplatz hat man zur Verfügung und welchen Overhead erzeugt die Komprimierung. In Systemen, in denen der Speicherplatz begrenzt ist, kann man einen solchen Schritt in betracht ziehen. Wenn jedoch ausreichend Speicherplatz verfügbar ist, würde ich persönlich auf eine Komprimierung verzichten.

Vielleicht ist die Archive Storage-Engine auch interessant für dich: https://dev.mysql.com/doc/refman/5.0/en ... ngine.html