Die Henne oder das Ei? MySQL Bzw. Firebird, oder PostgreSQL
-
Himmelherrgott... Wie komm ich immer auf Cosi... SOCI meine ich. Mensch... Sorry.
-
Aus Erfahrung (habe Mysql und Postgresql probiert) würde ich als
kostenlose Datenbank auch Postgresql empfehlen. Das ist auch was
für den Anwendungsentwickler, da Postgresql auch eine
High-Level-Programmierschnittstelle ala Oracle und DB/2 mit
exec sql... und Hostvariablen hat. Das macht die Entwicklung
(für mich persönlich - da vom IBM-Host kommend) wesentlich
einfacher und übersichtlicher als das Gefummel mit
Funktionsaufrufen und dem Parameterzusammensuchen.
Desweiteren würde ich die Bilder im Dateisystem ablegen und
wie schon Vorposter gesagt haben, nicht in der Datenbank - da nur
den Verweis. Postgresql bietet auch die Möglichkeit, wie die großen - grins
Tablespaces zu definieren. Da kann man dann auch z. B den Index und
die Daten einer großen Tabelle auf verschiedene Platten legen - bringt auch
einiges an Performance.
So einfach ist ein Insert mit Postgresql in C. Verzeit das Goto - ich
komme aus der Cobol-Assembler-Welt der S/370 - ja ich hab noch Lochkarten
gestanzt - grins.exec sql begin work;
exec sql insert into pferdlock values (:programm, :userid);
if (sqlca.sqlcode < 0) goto schluss1;
exec sql commit work;
-
Ich spiel seit etwa einem Jahr - eigentlich nur so zum Spass und Lernen - mit Firebird rum und bin ziemlich angetan davon. Ich teste das ganze aus einer MFC Anwendung heraus. Für die Kommunikation zur Datenbank verwende ich ADO in einer Selbstbau Kapselung - Quasi per msadoxx.dll Direktimport. Der Rest läuft dann per Microsoft OLEDB via ODBC Treiber, der auf dem standard Firebird ODBC Treiber aufsetzt (Mit den Firebird OLEDB Providern hab ich leider keine guten Erfahrungen gemacht). Mit dieser Schnittstelle funktioniert das wunderbar und wenn ich mich halbwegs an die SQL Standards halte (da ist Firebird erfreulicherweise sehr konform) kann ich auch relativ problemlos ein anderes DBMS, z.B. Oracle ranklemmen. Das einzige was mich an Firebird stört ist der Umfang erhältlicher Tools. Da ist wirklich kaum was brauchbares (kostenloses) zu finden um die Datenbank aufzusetzen. Man macht viel "per Hand", also SQL Konsole oder schreibt sich seine eigenen Tools. Ich werd mir in Zukunft mal Postgre ansehen, bin da auch ein wenig neugierig geworden.
-
Ich finde bei PostgreSQL insbesondere das Admin-Tool sehr gut gelungen (Tabellen, Indizes, Trigger, Prozeduren, ... erstellen geht damit wirklich einfach und schnell).
-
Hi Shogun,
ich hatte fast die gleiche Aufgabenstellung: Archivierung von TIFFs, PDF und
Textdaten, Aufkommen bis 100 Mio / Jahr, Umfang ca. 120-140 GB / Jahr (also ein
kleines bißchen weniger :)).Das ganze mit maximaler Verfügbarkeit und täglichem Dateimport.
Die Laufzeiten mit Standarddatenbanken (in diesem Fall Btrieve) waren immens,
also ein eigenes System. Da, wie bei Dir, keine Daten mehr geändert werden müssen,
kannst Du den ganzen Oberhead für Record-Locking etc. rauswerfen und voll auf
die Laufzeit und die sichere Speicherung gehen (man muß den Kram auch mal sichern,
vergiß das nicht. Bei großen Dateien machen alle OS schlapp).Die 4GB-Grenze ist auch tückisch, auch bei 2 GB aufpassen. Oberhalb von 4 GB wird
Windows etwas krückelig.Ich habe alles tageweise ebgelegt und dann über alles einen großen Index zum
Suchen gelegt. Es sind reine sortierte ASCII-Tabellen, mit einer Paar Vergleichen
habe ich den passenden Record. Die Suchzeiten sind trotz der Datenmenge recht
flott und liegen meist im Bereich 0.1-0.3 sec.
-
unterstützt jedes windows xp 4 cores? ich kenne mich da wenig aus. grundsätzlich sollte man sich aber wohl eher den einsatz eines unix überlegen, wenn man postgresql oder ähnliche einsetzen möchte. ein argument wäre, dass für eine spätere erweiterung keine lizenzkosten für das os benötigt werden.
postgresql unterstützt so etwas wie events. die sql kommandos listen und notify sind dafür zu verwenden. ich habe das selbst nie ausprobiert. ich weiß nur, dass es sie gibt.
postgresql verwendet mvcc. das könnte probleme mit den großen dateien probleme machen, hat aber vorteile bei gleichzeitigen zugriffen, die du ja anscheinend oft hast. mysql kann mvcc mit innodb und der neuen falcon engine auch.
postgresql unterstützt auch trigger und stored procedures. man liest, dass postgresql auf mehreren cores besser skaliert als mysql. es unterstützt mehr sql features als mysql, wobei hier mysql schneller aufholt als postgresql erweitert wird.
postgresql steht unter der bsd lizenz und ist ein reines community projekt. mysql hat eine firma hinter sich. seit jahren tauchen immer wieder gerüchte bezüglich des endes der open source variante auf. man sollte das bedenken.
-
noch ein argument für unix: die dateigröße ist mehr oder weniger nur von der festplattengröße beschränkt.
-
und wo ist da der unterschied zu dem bösen system aus redmond?
-
hjghjg schrieb:
und wo ist da der unterschied zu dem bösen system aus redmond?
nicht böse. meina rugment ist, dass für auf unix systemen entwickelte datenbanksysteme ein windows nicht voraussetzung ist und damit ökonomisch nicht sinnvoll. voraussetzung ist ein admin, der unix qualifikationen hat.
-
besserwisser schrieb:
man liest, dass postgresql auf mehreren cores besser skaliert als mysql.
_Viel_ besser.
es unterstützt mehr sql features als mysql, wobei hier mysql schneller aufholt als postgresql erweitert wird.
Klar, Postgres ist ja in punkto Standardunterstützung schon wesentlich näher an der Feature-Completeness dran, als MySQL. Und auch wenn es natürlich stimmt, dass InnoDB hier wesentlich stärker ist, so hat dies doch auch eine Menge Nachteile.