Für welche Datenbank würdet ihr euch entscheiden?
-
postgreSQL, weil es mehr SQL Befehle unterstützt, also mehr kann als MySQL.
Verglichen mit postgreSQL ist MySQL so ne Art liteSQL.
Anderseits ist MySQL natürlich sehr benutzerfreunlich, das
macht postgreSQL wiederum nicht so gut.Zu Oracle kann ich leider nichts sagen.
-
hm, interessant.
warum gibt es denn dann BLOB-felder, wenn man dokumente nicht in seiner datenbank speichern soll?
-
können != sollen
-
Wir speichern die Dateien zu solchen und ähnlichen Systemen auch als BLOBs in der Datenbank. Natürlich in eigenen Tabellen, etc, aber nur so kann man die Konsistenz garantieren. Wenn ich zum Beispiel zu Produkten noch Fotos o.ä. habe, oder Meßtabellen (Excel), dann packen wir die dazu. Gerade weil es ein riesiges System mit einigen Mio Datensätzen ist - sonst müßte man die Dateiabsicherung und Konsistenz separat durchführen. Auch ist das sehr schön, weil man z.B. nach einigen Wochen dann einfach BLOBs eines gewissen Alters löschen kann, das ist nahtlos integriert.
Es gibt in den Datenbanken genug Einstellmöglichkeiten, um sicherzustellen, daß durch die BLOBs der Tabellenspeicher der "normalen" geordneten Datensätze (konstante Länge) nicht zusätzlich fragmentiert werden.
-
Dieser Thread wurde von Moderator/in Marc++us aus dem Forum Themen rund um den PC in das Forum Datenbanken verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
bei postgresql ist die maximale größe eines feldes 1 GB. was ist denn, wenn der benutzer seine dvd-sammlung archivieren will? klar, kann man sagen, dass er das nicht darf aber wie könnte man seinen wunsch trotzdem realisieren? bietet postgresql verteiltest speichern in mehreren feldern von gesplitteten dateien?
-
Schlechtes Beispiel... eine DVD würde man wohl streamen wollen, das passt nicht gut zu BLOBs und Datenbanken, ohne daß man die Datei in Segmente zerlegt. Außerdem wird ein BLOB bei den mir bekannten Systemen immer am Stück zurückgeliefert, steht also im Speicher. Da braucht man schon eine Monstermaschine, um das zu können.
GB-Dokumente sehe ich auch nicht mehr in einer Datenbank gut aufgehoben, aber die typischen MB-Dokumente (Bilder, Grafiken, Autocadzeichnungen, Worddoks, Excel) machen sich da recht gut.
-
Wie wärs denn mit Firebird? Teste seit Anfang des Jahres damit rum und bin ziemlich begeistert. Allerdings muss man sich das ganze Administrationszeug erstmal zusammensuchen. Mitgeliefert wird lediglich eine SQL Konsole
http://www.firebirdsql.org
-
jimmy o tool schrieb:
bei postgresql ist die maximale größe eines feldes 1 GB.
Diese Einschränkung gilt aber nur bytea Strings. BLOBs sind davon nicht betroffen. Allerdings muß man BLOBs in PostgreSQL anders handhaben als bytea Felder.
-
[quote=\"~john\"][quote=\"jimmy o tool\"]bei postgresql ist die maximale größe eines feldes 1 GB.[/quote]
Diese Einschränkung gilt aber nur bytea Strings. BLOBs sind davon nicht betroffen. Allerdings muß man BLOBs in PostgreSQL anders handhaben als bytea Felder.[/quote]aha und weißt du wie groß blobs werden dürfen? inwiefern müssen sie denn anders gehandhabt werden?
-
jimmy o tool schrieb:
aha und weißt du wie groß blobs werden dürfen? inwiefern müssen sie denn anders gehandhabt werden?
Bei Blobs wird in Postgres IIRC ohnehin nur die OID in der Tabelle abgelegt, der Rest liegt im Dateisystem, das insofern wohl am ehesten der limitierende Faktor sein wird.
-
Bei Blobs wird in Postgres IIRC ohnehin nur die OID in der Tabelle abgelegt, der Rest liegt im Dateisystem, das insofern wohl am ehesten der limitierende Faktor sein wird.
hört sich doch toll an. für mich hört sich das so an, als ob die datenbank sich darum kümmert, dass die datei richtig abgespeichert wird. somit kann man die datenbank auf linux installieren und wenn man seine dokumente in blob-feldern speichert muss man sich nicht um die samba-kacke kümmern, um an die dateien ranzukommen unter windows-clients.
-
Das klingt für mich nicht sehr sinnvoll. Wenn Du Samba brauchst, dann nimm Samba, kein RDBMS.
-
[quote=\"nman\"]Das klingt für mich nicht sehr sinnvoll. Wenn Du Samba brauchst, dann nimm Samba, kein RDBMS.[/quote]
ich vestehe deine aussage nicht.
wenn ich alles in der datenbank speichere, brauche ich solche sachen wie samba nicht. ich kann mich ganz allein auf den datenbankzugriff konzentrieren.weitere vorteile: man muss immer nur ein backup von der datenbank machen und nicht noch extra vom fileserver. man braucht die rechtevergabe nicht in der software realisieren, sondern kann sich auf die rechtevergabe der datenbank verlassen.
-
Sogar MS geht nun dazu über in SQL Server 2008 die BLOB in Dateien abzulegen.
Das Verwaltet dann aber MSSQL selbst.
Scheint also für das Tempo keine gute Idee zu sein.
Bei kleinen Datenbanken macht dies sicher nicht aber bei uns hat sowas schon mal 40 GB und mehr mit mehreren Millionen Datensätzen.
Das muss man dann auch mal konsistent sichern und dauert ewig.
-
Unix-Tom schrieb:
Bei kleinen Datenbanken macht dies sicher nicht aber bei uns hat sowas schon mal 40 GB und mehr mit mehreren Millionen Datensätzen.
Ist der gesamte Dump so groß, oder die jeweiligen Dateien?
Unix-Tom schrieb:
Das muss man dann auch mal konsistent sichern und dauert ewig.
Konsistent sichern ist doch nicht das Problem. Entweder man hält das DBMS an, dann geht der Dump sehr schnell, oder man läßt das DBMS weiter laufen, dann dauert der Dump etwas länger. Konsistent ist er so oder so. Wie schnell man einen Dump erstellen kann hängt maßgeblich vom Rechner ab. Sicherlich gibt es bei dem letztem Punkt viele Sachzwänge.
-
wieso glaubst du das ein Dump einer Tabelle mit 40 GB an BLOB-Daten schnell gehen soll?
Wie Du sicher weißt wird bei der Sicherung jede Tabelle alleine gesichert.
Was aber wenn es ref, Trigger und ähnliches gibt.
Die Sicherung hält sich mit dem Sichern von Daten auf die auch im Dateisystem stehen könnten.
Es soll auch RDBMS geben die man im laufenden Betrieb sichern muss!
Ist aber bei uns egal da es sowieso Spiegelserver sind.
-
Unix-Tom schrieb:
wieso glaubst du das ein Dump einer Tabelle mit 40 GB an BLOB-Daten schnell gehen soll?
Warum sollte er lange dauern? Ohne nähere Angabe, was für ein Rechner und welches DBMS es ist, ist das ziemlich sinnlos über den Zeitbedarf zu reden. Auf einem BigIron ist der Zeitbedarf nicht mal erwähnenswert, und eine kleine Maschine hyperventiliert, um die Daten zu kopieren.
Die Sicherung hält sich mit dem Sichern von Daten auf die auch im Dateisystem stehen könnten.
Ein Dump läßt sich anpassen. Ich sehe da beim besten Willen kein Problem.
Es soll auch RDBMS geben die man im laufenden Betrieb sichern muss!
Ja und? Ich sehe immer noch kein Argument, was es rechtfertigen würde wichtige Dateien statt im einem BLOB in einer externen Datei abzulegen. Wenn man BLOBs als Dateiablage benutzt, dann benötigt man meist in der Datenbank zusätzliche Informationen über diese Dateien die man bei einer Verknüpfung über einen Dateinamen nicht so gut ablegen kann. Warum soll ich mir eine Fehlermöglichkeit einhandeln, weil ich DB und Dateien getrennt ablegen?
Ist aber bei uns egal da es sowieso Spiegelserver sind.
Ein Spiegelserver ersetzt kein Backup.
-
also irgendwie hab ich noch kein argument gefunden, was nicht wiederlegt wurde, warum man seine dateien nicht in der datenbank speichern soll.
-
hier nochmal die vorteile, dir mir spontan einfallen:
- man muss nur die datenbank sichern und nicht zusätzlich noch seinen fileserver
- man braucht die berechtigung auf die dateien nicht in der software zu implementieren, sondern kann sich auf die datenbank verlassen
- man ist unabhängig vom betriebssystem bzw. dateisystem. man kann die datenbank auf linux installieren und muss die ganze samba-sache nicht einrichten, wenn man auf seine dateien zugreifen will
- dateien sind immer konsistent