also wenn es um "transaktionsfreie" Tabellen geht, kannst Du Dir mal die "unlogged tables" der aktuellen 9.1 ansehen. Pro PostgreSQL: Ich persönlich finde die Window Functions Klasse. Auch gefällt mir in dem Zusammenhang die Möglichkeit, Funktionen und Trigger in SQL oder Perl zu schreiben. Ich stecke gerne soviel Logik wie möglich in die DB. Damit können die verschiedenen Clients so dumm wie möglich sein und Änderungen müssen nur an einer Stelle eingepflegt werden. Ist aber ein Punkt, über den man auch lange Philosophieren kann (Erinnert sich noch Jemand an die Zeit, als MySQL noch keine Fremdschlüssel konnte? Wenn man dieses Feature auf der Mailingliste auch nur Erwähnt hat, wurde man seitenweise zugetextet, dass dies nicht Aufgabe der DB sei, sondern alle Entwickler dies lieber in der Anwendungslogik haben, zwecks besserer Kontrolle ). Bezüglich Tools zur Migration: Da gibt es doch einiges (von Enterprisedb bspw.) und eine Menge Tutorials. Habe jedoch noch keine Migration v. MySQL durchgeführt, kann also nichts über etwaige Probleme sagen.
Mal anders herum gefragt: Gibt es irgendeinen Grund bei einen neuen Projekt *nicht* auf PostgreSQL zu setzten? (Außer wenn man eine file based DB haben will. Da hat man nur die Wahl zwischen SQLite und MySQL.)
also wenn es um "transaktionsfreie" Tabellen geht, kannst Du Dir mal die "unlogged tables" der aktuellen 9.1 ansehen.
).
Pro PostgreSQL: Ich persönlich finde die Window Functions Klasse. Auch gefällt mir in dem Zusammenhang die Möglichkeit, Funktionen und Trigger in SQL oder Perl zu schreiben. Ich stecke gerne soviel Logik wie möglich in die DB. Damit können die verschiedenen Clients so dumm wie möglich sein und Änderungen müssen nur an einer Stelle eingepflegt werden. Ist aber ein Punkt, über den man auch lange Philosophieren kann (Erinnert sich noch Jemand an die Zeit, als MySQL noch keine Fremdschlüssel konnte? Wenn man dieses Feature auf der Mailingliste auch nur Erwähnt hat, wurde man seitenweise zugetextet, dass dies nicht Aufgabe der DB sei, sondern alle Entwickler dies lieber in der Anwendungslogik haben, zwecks besserer Kontrolle
Bezüglich Tools zur Migration: Da gibt es doch einiges (von Enterprisedb bspw.) und eine Menge Tutorials. Habe jedoch noch keine Migration v. MySQL durchgeführt, kann also nichts über etwaige Probleme sagen.
Grüße p
Mal anders herum gefragt: Gibt es irgendeinen Grund bei einen neuen Projekt *nicht* auf PostgreSQL zu setzten? (Außer wenn man eine file based DB haben will. Da hat man nur die Wahl zwischen SQLite und MySQL.)