Für welche Datenbank würdet ihr euch entscheiden?
-
Hi,
nur mal angenommen, ihr wollt eine Software schreiben, die eine Datenbank benötigt, z.B. ein Warenwirtschaftssystem. Die Datenbank soll kostenlos sein.
Worauf würdet ihr setzen?
MySQL, postgreSQL oder Oracle Express?Oracle Express hat die Einschränkung, dass die Datenbank maximal 4GB groß werden kann.
Alle Datenbanken laufen auf Windows und Linux.
Wenn die Software Dokumente und Bilder verwalten soll, ist es dann besser diese auf einem Netzlaufwerk zu speichern oder speichert man sowas auch in der Datenbank (dann kann Oracle Express nämlich schnell an seine Grenzen stoßen)?
Hier nochmal eine Vergleichsmatrix: http://www.id.uzh.ch/dl/sw/Angebot/datenbanken/vergleich.html
-
Ich würde mich wohl für Postgres oder DB2 Express entscheiden. Wenn ich vorher noch nichts mit Datenbanken gemacht hätte, würde ich vermutlich Postgres wählen. Da ich mich mit DB2 aber auskenne würde ich wohl DB2 Express vorziehen. Die hat übrigens keine nennenswerten Einschränkungen.
Dokumente (hauptsächlich PDF und RTF Dokumente) speichere ich, und würde ich jederzeit wieder, in der Datenbank. Einfach weil so sichergestellt ist, das die Dokumente und Verweise darauf stets konsistent sind. Ausserdem kann ich da erzwingen, dass der Kunde tägliche Backups macht. Bei Files kann ich das nicht so einfach sicherstellen.
-
1. MySQL oder PostgreSQL. Wobei MySQL am verbreitetsten ist, d.h. du hast eine große Community an die du dich bei Problemen wenden kannst.
2. Dateien gehören auf keinen Fall in eine Datenbank, sondern auf ein NFS. Eine Datenbank ist zum speichern von Datensätzen da. Für Dateien gibt es Dateisysteme.
-
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.