Hallo Sir Q,
die Dokumentation von PostgreSQL ist ausreichend gut, an manchen Stellen ist die Übersicht (fehlende Indexeinträge) nicht so toll, aber es gibt mittlerweile Literatur, die dieses Manko behebt.
Wir mußten die Erfahrung machen, daß MySQL unter Umständen heftige Performance Probleme hat (4.0.x). Wir hatten eine DB bei der bei einer Abfrage die WHERE CLAUSE nicht richtig ausgewertet wurde (Bug in MySQL), so daß nur eine Teil der Bedingung ausgewertet wurde und dann die Daten aus der DB geholt wurden und danach die restlichen Bedigungen. Der Unterschied war; statt 0.1s hat die Abfrage >30s gedauert und ca. 200MB RAM/Abfrage auf der dedizierten DBMS Maschine aufgefressen.
Erst mit InnoDB wird MySQL zu einem RDBMS, MyISAM ist aber immer noch unter Linux/UNIX Vorgabe.
Ich würde Stored Procedures nicht als "Gimmicks" bezeichnen. Mit ihnen erst werden Trigger möglich, so daß man neben Table Constraints das Datenmodell automatisch validieren kann und die Gefahr von kaputten Datensätzen in der DB drastisch reduzieren wird.
Stored Procedures haben den weiteren Vorteil, daß man komplizierte Abfragen direkt auf dem DBMS Server durchführen kann, die man andernfalls nacheinander an den Server absetzen müßte und die Ergebnisse der Client bearbeiten müßte. Das ist vorallem in Multi-Tier Lösungen sinnvoll/notwendig, da hier DBMS Server und Client auf unterschiedlichen Server laufen, und man über die Stored Procedures den Kommunikationsaufwand stark reduzieren kann.
Es gibt mittlerweile Replication auch für PostgreSQL, eine absolute Notwendigkeit, wenn man Lösungen braucht, die eine hohe Verfügbarkeit aufweisen müssen. (Hier hatte MySQL die Nase vorne.) Unterm Strich sehe ich klare Vorteile für PostgreSQL, wenn es um die Absicherung der Daten geht.
Bei MySQL wurden die Unzulänglichkeiten auch erkannt und es wird angefangen diese Lücken zu stopfen. MaxDB ist nicht jedermanns Sache.
die Dokumentation von PostgreSQL ist ausreichend gut, an manchen Stellen ist die Übersicht (fehlende Indexeinträge) nicht so toll, aber es gibt mittlerweile Literatur, die dieses Manko behebt.
Wir mußten die Erfahrung machen, daß MySQL unter Umständen heftige Performance Probleme hat (4.0.x). Wir hatten eine DB bei der bei einer Abfrage die WHERE CLAUSE nicht richtig ausgewertet wurde (Bug in MySQL), so daß nur eine Teil der Bedingung ausgewertet wurde und dann die Daten aus der DB geholt wurden und danach die restlichen Bedigungen. Der Unterschied war; statt 0.1s hat die Abfrage >30s gedauert und ca. 200MB RAM/Abfrage auf der dedizierten DBMS Maschine aufgefressen.
Erst mit InnoDB wird MySQL zu einem RDBMS, MyISAM ist aber immer noch unter Linux/UNIX Vorgabe.
Ich würde Stored Procedures nicht als "Gimmicks" bezeichnen. Mit ihnen erst werden Trigger möglich, so daß man neben Table Constraints das Datenmodell automatisch validieren kann und die Gefahr von kaputten Datensätzen in der DB drastisch reduzieren wird.
Stored Procedures haben den weiteren Vorteil, daß man komplizierte Abfragen direkt auf dem DBMS Server durchführen kann, die man andernfalls nacheinander an den Server absetzen müßte und die Ergebnisse der Client bearbeiten müßte. Das ist vorallem in Multi-Tier Lösungen sinnvoll/notwendig, da hier DBMS Server und Client auf unterschiedlichen Server laufen, und man über die Stored Procedures den Kommunikationsaufwand stark reduzieren kann.
Es gibt mittlerweile Replication auch für PostgreSQL, eine absolute Notwendigkeit, wenn man Lösungen braucht, die eine hohe Verfügbarkeit aufweisen müssen. (Hier hatte MySQL die Nase vorne.) Unterm Strich sehe ich klare Vorteile für PostgreSQL, wenn es um die Absicherung der Daten geht.
Bei MySQL wurden die Unzulänglichkeiten auch erkannt und es wird angefangen diese Lücken zu stopfen. MaxDB ist nicht jedermanns Sache.