Für welche Datenbank würdet ihr euch entscheiden?
-
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
-
hm.... ihr habt mich ins Grübeln gebracht...
Ich hab bsiher Dateien separat von der DB gespeichert... die Vorteile, die ich darin sehe sind folgende: (ihr könnt sie gerne entkräften)- Auf die Dateien kann auch ohne DB zugegriffen werden (z. B. Up- und Download von Galeriebildern)
- Entlastung der DB
- zu faul zum nachdenken grad
und entscheidet sich die Eignung, die Datei in der DB statt im FS abzulegen nur anhand der Dateigröße (KB/MB-Bereich), oder gilt es da auch andere Faktoren zu beachten (Häufigkeit der Änderung, Lastenausgleich, etc)
-
- Auf die Dateien kann auch ohne DB zugegriffen werden (z. B. Up- und Download von Galeriebildern)
hey,
das kommt natürlich drauf an, was du vor hast. wenn du daten schützen möchtest, sollten sie besser in die DB. wenn sie in der DB liegen, brauchst du immer ein tool um sie aus der DB wieder rauszukriegen. du kannst von einem endbenutzer erwarten, dass er SQL kann.
-
hi ich bin neu in Datenbank programmierung. Jedoch möchte ich einfach ein bisschen mit einer datenbank programmieren. Ich möchte sie benutzen um zu einem nutzer verschiedene informationen abspeichern zu können. ich weiss nicht wie viel man für ien datenbank braucht. was für eine datenbank würde4t ihr mir empfehlen? ich möchte keinen ganzen server installieren.
-
Hi,
-
also ich würde mich dann für SQLite entscheiden. was brauche ich dafür um eine Datenbank mit C++ zu erstellen und auf die ich dann auch mit dem Programm zugreifen kann?
-
Es gibt da verschiedene Ansätze. Mach dich mal schlau zum Thema ODBC oder ADO. Mit ODBC und MFC kannst du relativ schnell kleine Datenbank Anwendungen entwickeln