Gibt es da eigentlich wichtige Unterschiede zu MySQL? Lese schon seit einer Weile von Postgre hier auf Prolinux, so bin ich meist aber doch eher auf MySQL getroffen. Würde mich mal interessieren ob die in etwa in die gleiche Kerbe schlagen oder doch ziemlich unterschiedliche Ansätze verfolgen.
PostgreSQL und MySQL sind zwei eigenständige Datenbanksysteme. Was soll die Grundlage für einen Vergleich darstellen? Spezifiziere bitte "in die gleiche Kerbe schlagen" näher.
Also erstmal gibt es nur einen Tabellentyp, mit dem alles abgehandelt werden kann, was du haben willst. So ist es zum Beispiel moeglich Transaktionssicherheit, mit Schluesselbeziehungen und Volltextsuche zu bekommen. Postgresql laeuft zudem sehr stabil, ist in Sachen SQL sehr restriktiv (man kann keinen Varchar in ein Numberfeld stecken), bietet Transaktionssicherheit auch ueber DDL-Befehle hinweg ... Das ist aber noch nicht alles, schau einfach mal auf http://www.postgres.de/features.html http://wiki.postgresql.org/wiki/FAQ/de
Ich wuerde dir empfehlen, es einfach mal zu installieren und auszutesten. Denn all die Sachen bringen nix, wenn man sich an die Ungereimtheiten von MySQL gewoehnt hat und sie nicht mehr ablegen will, wie zum Beispiel die ``.
Insgesamt ist der Funktionsumfang bei Postgres größer. Bei simplen "Select * From tabelle" tut sich das nicht viel, aber darüber hinausgehend sind ein paar nette Dinge dabei, wie "composite datatypes", Arrays, ... Leider kommt phppgadmin nicht an phpmyadmin heran und PgAdmin III ist auch keine große Leuchte...
Ja, die teils etwas kruden Tools sind mir bei meinen Tests auch immer wieder etwas unangenehm aufgefallen. Mag MySQL auch kein perfekter SQL Server sein (sofern es soetwas überhaupt gibt ), bequem zu bedienen dank wirklich guter Client Tools.
Allerdings sollte man mit Aussagen wie "Insgesamt ist der Funktionsumfang bei Postgres größer" vorsichtig sein. MySQL entwickelt sich schnell weiter, soetwas gilt in vielen fällen oft nicht mehr lange.
Zudem sollte man MySQL immer passend zur Aufgabe betrachten, immerhin kann MySQL vieles sein, von reinem Highspeed Readonly Datenlieferanten, bis zur verlässlichen zentralen Firmen-DB. Das erfordert teils aber deutlich andere herangehensweisen an die DB, ihre Einstellungen und die Wahl der Tabellentypen.
Pauschale Aussagen sind da immer etwas schwer. MySQL kann schneller sein als PostgreSql, oder langsamer. MySQL hat Funktionen besser integriert, andere schlechter. Manches ist simpler, aber brauchbarer. Es kommt immer darauf an was man machen möchte.
Allerdings sollte man mit Aussagen wie "Insgesamt ist der Funktionsumfang bei Postgres größer" vorsichtig sein. MySQL entwickelt sich schnell weiter, soetwas gilt in vielen fällen oft nicht mehr lange.
"In vielen Fällen" macht die Sache deutlich ;-)
Zur Erfüllung einer aus meiner Sicht grundlegenden Anforderung für Datenbanken hat's sehr lange gebraucht.
http://de.wikipedia.org/wiki/ACID
Zudem sollte man MySQL immer passend zur Aufgabe betrachten, immerhin kann MySQL vieles sein, von reinem Highspeed Readonly Datenlieferanten, bis zur verlässlichen zentralen Firmen-DB.
Ob PostgreSQL auch beim einfachsten Andwendungsfall immer noch nennenswert langsamer ist, vermag ich nicht zu beurteilen. Zu PostgreSQLs 6er-Zeiten war MySQL dabei erheblich schneller. Bei komplexeren Abfragen und zunehmender Anzahl der Clients brach MySQL völlig ein, während PostgreSQL durchstampfte. Wobei PostgreSQL schon damals Abfragen erlaubte, für deren Ermöglichung MySQL noch einige Jahre brauchte.
Zur "verlässlichen zentralen Firmen-DB": gerade für diesen Anwendungsfall traue ich PostgreSQL mehr zu. Schon damals war es möglich, die Anwendungslogik in die Datenbank zu verlegen.
Wieso sollte man ein System nutzen, welches hinsichtlich der Funktionalität aufschließen mußte? Und lange übelste "Gotchas" aufwies?
Einschränkung: bzgl. Cluster und Replikation steht MySQL nach meiner Kenntnis besser dar.
Das erfordert teils aber deutlich andere herangehensweisen an die DB, ihre Einstellungen und die Wahl der Tabellentypen.
Das Problem der verschiedenen Backends, die mal dieses, aber nicht jenes können, stellt sich bei PostgreSQL nicht.
Pauschale Aussagen sind da immer etwas schwer.
Sehe ich anders. PostgreSQL ist mächtiger. Auch wenn MySQL z.B. inzwischen Trigger kennt, entnehme ich der aktuellen MySQL-Dokumentation, dass bei PostgreSQL damit mehr möglich ist.
Manches ist simpler, aber brauchbarer.
Verstehe ich nicht. Ein Beispiel?
Es kommt immer darauf an was man machen möchte.
Sicher reicht MySQL für vieles ;-)
PS: als Client reich(t)en mir unter beiden Systemen meist die jeweiligen Konsolen. PgAdminIII ist aber ein sehr schönes Tool, um z.B. Trigger und Funktionen zu bearbeiten. Scheint mir tiefer zu liegen, als PHP-Oberflächen.
Bei deinen Tests? Nur rumtesten bringt gar nix, man muss damit mal in der Praxis gearbeitet haben.
Ich für meinen Teil finde die MySQL Tools irgendwie verwirrend, warum mehrere Tools. Mit PgAdmin 3 hat man ein ganz einfaches leistungsfähiges Tool zur Wartung und Performance Analyse/Optimierung. Die Frage ist was macht man denn groß mit solchen Tools, Backups werden meist über Scripte gefahren, User legt man selten an. Tabellen ändert man in der Regel nicht. Das einzige was ich mit so einem Tool mache ist mal nen Index anlegen, ein paar SQL Abfragen zu tätigen etc. da ist mir das einfache PgAdmin viel lieber, die Usability von MySQL Admin bzw Query Browser finde ich nicht so prickelnd.
Um ein DB Schema zu entwickeln kannst du weder die MYSQL noch die PostgreSQL Tools brauchen, da braucht man dann sowas wie Toad.
phppgadmin hab ich noch nie verwendet, aber PgAdmin III finde ich sehr gelungen. Ich arbeite viel lieber mit PgAdmin als mit phpmyadmin oder MySql Admin/Query Browser.
MySQL und PostgreSQL haben unterschiedliche Zielgruppen, kurz und polemisch könnte man sagen: MySQL ist die Basis für zusammengefrickelte Webapps, PostgreSQL ist die Basis für langweilige ERP Anwendungen. Oder: MySQL ist schnell, PostgreSQL ist standardkonform. Oder: MySQL ist laut aber PostgreSQL riecht besser. Whatever. Kommt drauf an. Wer hätte das gedacht?
Das liegt daran, das MySQL für die gleiche Aufgabe mehr CPU Zyklen braucht als postgresql, was an den Kontextumschaltungen zwischen den inzwischen Dreiundsechzig(?) verschiedneen Backends liegt, was wiederum zum einen den Lüfter anschmeißt und zum anderen aufgrung heißgelaufener CPU diesen MySQL typischen Geruch von verbranntem Silikon erzeugt, den man sonst nur von pupertierenden Vista besessenen Egoshooterspielern kennt.
Ich hab bisher noch keine ERP Umgebung gesehen in der Postgres gelaufen ist, erp Systeme sind ja oftmals konstenpflichtige Systeme, bei denen man in der Regel immer eine kostenpflichtige mit Enterprise Support erhältliche DB nutzt. Offensichtlich hast du sehr bis sehr sehr wenig Ahnung.
Postgres wird z.B. sehr gern dort eingesetzt wo es um Geolocation geht oder um sehr große DBs. Ich entwickle zur Zeit eine Anwendung, bei der sich bis zu 50Mio Datensätze in der DB befinden (das Schema hat ca 30 Tabellen mit je 5-15 Feldern, läuft auf nem Quad Xeon mit 4GB RAM und nem Raid5 aus SAS Platten), Postgres macht dabei eine ausgezeichnete Figur vor allem weil es automatisch die Abfragen analysiert und danach selbst optimiert, autovaccum lässt sich nach dem eigenen Bedürfnissen konfigurieren etc.
Wenn ich mal zuviel Zeit habe möchte ich mit den Daten mal einen Benchmark machen, wäre schon interressant wie sich MySQL bei so einer DB Größe schlägt.
Ich hab bisher noch keine ERP Umgebung gesehen in der Postgres gelaufen ist, erp Systeme sind ja oftmals konstenpflichtige Systeme, bei denen man in der Regel immer eine kostenpflichtige mit Enterprise Support erhältliche DB nutzt. Offensichtlich hast du sehr bis sehr sehr wenig Ahnung.
Naja, eine Art KMU-ERP im weiteren Sinne habe ich mal erstellt. pl/R sei gedankt. Kam bei der Kreditversicherungen gut an, sowas hätten sie noch nicht gesehen.
Postgres wird z.B. sehr gern dort eingesetzt wo es um Geolocation geht oder um sehr große DBs.
Der Umgang mit geographischen Daten dürfte eine Stärke von PostgreSQL sein.
Wenn ich mal zuviel Zeit habe möchte ich mit den Daten mal einen Benchmark machen, wäre schon interressant wie sich MySQL bei so einer DB Größe schlägt.
Aber abseits der Größe bitte mit dem richtigen Backend für Geodaten. SCNR
Sorry, Lord. Ich habe schone diverse ERP installationen gesehen, die PostgreSQL als Backend verwenden. Aus verständlichen Gründen (Performance, Nähe zum SQL Standards, Nähe zu Oracle-"Standards" etc.). Nur gibts halt auch viele Anbieter die dies nicht würdigen und lieber "geht auch mit MySQL" hausieren gehen, auch wenn sie nicht wirklich dahinter stehen.
Oh, und Enterprise Support für PostgreSQL existiert.
Wieviel Ahnung ich von dieser Materie habe, kannst du kaum beurteilen. Oh, ich sehe greade: du entwickelst eine Anwendung mit einem so wahnsinnig komplexen Schema mit ca. 30 Tabellen. 50Mio Datensätze, Maschinen mit 4GB RAM. Und findest das Aufregend. Natürlich bist DU der König aller Datenbankanwendungen. Hast du JEMALS ein "echtes" ERP auch nur aus Distanz gesehen? Eher nicht, oder?
Von Jochen Plumeyer am Fr, 17. April 2009 um 18:29 #
> Schema mit ca. 30 Tabellen. 50Mio Datensätze ...
Hihi, der war echt gut.
Bei solchen Datenmengen reicht normalerweiser SQLite, wenn nicht parallel beschrieben wird. (Für Prototypen oder Single-User-Anwendungen finde ich ist SQLite unglaublich gut, was Funktionsumfang und Effizienz angeht.)
Replikation/ Clusterfähigkeit: Das kenn ich nur vom Lesen, aber ich habe recht viele Einschränkungen bei MySQL gesehen, bei PostgreSQL gibt es eine Vielzahl von Lösungen, die anscheinend recht reif sind.
>>>Bei solchen Datenmengen reicht normalerweiser SQLite, wenn nicht parallel beschrieben wird.
LOL. Ich lach mich gerade tot. Die Anwendung die ich jetzt als Webanwendung realisiere war zuvor mal als Single User Python Anwendung mit SQLite realisiert, die Performance war dabei bei 100 000 Datensätzen schon unterirdisch schlecht. Das Problem an meiner Anwendung ist nämlich, dass ich nicht wie bei Spielzeuganwendungen mal schnelle den Inhalt des letzten Eintrags auslese, sondern z.B. Distincts über ein paar Millionen Tupel mit Strings laufen lassen muss.
>>>Oh, ich sehe greade: du entwickelst eine Anwendung mit einem so wahnsinnig komplexen Schema mit ca. 30 Tabellen. 50Mio Datensätze, Maschinen mit 4GB RAM
Ich hab auch schon Anwendungen für MySQL Cluster (mehrere Master und 150 Slave Server) entwickelt, diese Anwendungen stellten aber keine große technische Anforderungen an die DB, da mussten halt nur täglich 100Mio User bedient werden, mit ganz einfachen Selects.
Das Projekt hier ist anders, geringe Userzahlen aber komplexe Abfragen mit sehr großen Ergebnismengen. Hier bringt mir z.B. ein MySQL Cluster gar nichts.
Dann sag mir doch mal welches Spielzeug ERP denn Postgres benutzt.
>>Hast du JEMALS ein "echtes" ERP auch nur aus Distanz gesehen? Eher nicht, oder?
Ich benutze eins jeden Tag um meine Stunden zu buchen--> SAP
Da du offensichtlich schon PostgreSQL in Verbindung mit ERP Systemen gesehen hast, scheinst du wohl im Bereich 5 Mann Betriebe tätig zu sein.
Ich bin hauptsächlich im Bereich Individualsoftware (ERP) tätig. Und davon gibt es viele, die auf PostgreSQL fussen. Weil die Entwickler (meist die Firmeninterne IT, manchmal auch externe Systemhäuser) die Vorteile dieser Datenbank sehen und kennen. Da kann ich dir verständlicherweise keine Namen nennen.
Meine Kritik wendete sich an die Anbieter von ERP Standardsoftware, die zwar wohl wissen (zumindest die Techniker) das ihr Produkt wunderbar mit PostgreSQL harmoniert, aber es leider nicht schaffen, dies auch ihren Marketing- und Vertriebsleuten beizubringen. Die kennen halt DB2, Oracle und Informix (oh, und natürlich MaxDB, aber das unterstützt aus verständlichen Gründen nur der ERP Marktführer) . Und wenn der Interessent nach der freien (wobei frei hier natürlich "..as in Beer", nicht "..as in Speech" bedeutet, die Einführung eines ERP-Systems hat meist einen kommerziellen, selten einen idiologischen Hintergrund... ) Datenbank frägt, gibts halt ein reflexartiges "MySQL". Liegt natürlich daran, daß hinter MySQL eine Firma mit kommerziellen Interessen steht und damit auch Marketing betreibt, und PostgreSQL eine Community-Entwicklung mit einer akademischen Historie. Da gibts keinen Vertrieb, kein Marketing, kein Markenbranding.
Und nein, mit 5 Mann Klitschen hab ich nichts zu tun.
>>>Meine Kritik wendete sich an die Anbieter von ERP Standardsoftware, die zwar wohl wissen (zumindest die Techniker) das ihr Produkt wunderbar mit PostgreSQL harmoniert, aber es leider nicht schaffen, dies auch ihren Marketing- und Vertriebsleuten beizubringen
Man muss aber auch eingestehen, dass PostgreSQL auch seine Defizite hat und daher nicht einfach immer empfehlenswert ist. Im Bereich Replikation ist Pg noch nicht da wo die Konkurrenz ist und gerade bei großen verteilten Projekten wäre das schon wichtig, da merkt man halt noch wo PostgreSQL seinen Ursprung hat:-)
100 % ACK. Jedes Datenbanksystem hat seine Stärken und Schwächen. Das ist genau das, was ich mit meinem ersten Posting hier sagen wollte. Ich hab nichts gegen MySQL und auch nichts gegen DB2 oder Oracle. Aber mich nerven Leute, die nur eines kennen (eben meist MySQL) und versuchen damit alle Probleme zu erschlagen ("Wer nur einen Hammer hat, für den sieht jedes Problem wie ein Nagel aus").
Für (richtig) grosse, verteilte (synchrone) Systeme ist PostgreSQL derzeit das falsche Werkzeug, ganz klar.
ich erinnere mich an den Film 'Der Flug des Phoenix". Hardy Krüger baut dort aus einem Wrack eine einmotorige Maschine. Als es herauskommt, dass er nur Flugzeugmodelle konstruiert und keine richtige große Flugzeuge, sind die Leute schockiert. Hardy kann es auch nicht fassen, dass die Leute den Modellflugzeugbau so gering schätzen und erklärt: 'aber Modellflugzeuge sind viel schwerer zu bauen als große Maschinen, die fliegen fasst von selbst'.
Ja, in der Tat, die Überheblichkeit der Leute, die schon SAP gesehen haben kotzt mich manchmal an.
> Ja, in der Tat, die Überheblichkeit der Leute, die schon SAP gesehen haben kotzt mich manchmal an.
Komischerweise kommen solche Aussagen immer von Leuten, die SAP maximal aus Anwendersicht kennen.
Meine persönliche Empfehlung: Erweitere deinen Horizont, bevor du solche Aussagen machst. Es gibt genug Möglichkeiten dazu. Selbst beim Hersteller. goto http://help.sap.com
> Komischerweise kommen solche Aussagen immer von Leuten, die SAP maximal aus Anwendersicht kennen.
Aha, das ist ja interessant, woher weißt du, dass diese Aussagen _immer_ von solchen Leuten kommen? Ich möchte darauf gar nicht tiefer eingehen, aber in einem hast du recht: Die SAP-Leute halten eng zusammen, können meist nicht viel aber verdienen Kohle ohne Ende. Bewundernswert. Sie halten den Stöpsel auf "ihrem hochwichtigen" System als Blackbox drauf und machen einen Riesentrara drum, so dass die Kohle in Größenordnungen ohne große Nachfragen fließt und kaum jemals wer nach Kosten-Nutzen fragt. Wirklich bewundernswert. Könnten sich viele andere IT-Bereiche ne Scheibe von abschneiden. Kenn ich sonst nur noch von Oracle-"Gurus" so.
Wenn du der Meinung bist "SAPler verdienen Kohle ohne Ende und müssen nicht viel können", warum bewirbst du dich nicht einfach bei einem der 1000 SAP Systemhäuser oder wirst Freiberufler. Es gibt trotz Krise Jobs & Projekte. Und nicht vergessen: gleich mal die Baufirma deines Vertrauens mit der Vergrösserung deiner Garage beauftragen, damit deine Ferraris dann auch reinpassen.
Im Ernst: Ich kann meine Aussage nur noch mal wiederholen: Mach dich erst mal schlau, was SAP ist, wie es funktioniert, was da alles dranhängt. Die Doku ist für jeden frei einsehbar (und das ist keineswegs selbstverständlich in der Branche!). Du kannst dir auch einen voll funktionsfähigen Netweaver runterladen und für einige Zeit testen. Das ist zwar "nur" die technologische Basis ohne ERP Komponenten, aber zum reinschüffeln in ABAP etc. locker ausreichend.
Oh ja: es gibt auch in der SAP-Beratungsbranche "Blender" (= Grosse Klappe, nix dahinter). Aber meiner Erfahrung nach nicht mehr, wie in anderen IT-affinen Branchen. Und die kommen entweder nicht weit (weil ihr fehlendes KnowHow schnell sichtbar wird) und schulen um zum Vorwerk Vertreter oder so weit, daß man mit ihnen nichts mehr zu tun hat (AKA Befördert).
zum Thema "5 Mann Betriebe": Nicht alles was hinkt, ist ein Vergleich.
Die Anforderungen eines "5 Mann Betriebes" (sagen wir mal Handwerksmeister, 3 Gesellen, 1 Lehrling) sind halt wesentlich geringer und komplett anders ein kleinerer mittelständischer Betrieb mit 250 Leuten. Da kann man nicht einfach hochskalieren.
ich habe beide Systeme benutzt, sowohl auf Software Ebene als auch auf der Datenbank Ebene. Nutzt man Persistenz Schichten in Java z.B. wie Hibernate oder Toplink (siehe JPA) sind zahlreiche Features der Datenkbanken nicht wirklich relevant. Fachlogik hat nichts in DB zu suchen - zu teure Folgekosten bei Pflege. In Punkto Geschwindigkeit ist meiner Erfahrung nach MySQL leicht vorne - da hält keine andere DB mit, in Punkto Stabilität ist PostGreSQL denke ich die bessere Wahl. Replikation, Clustering usw. hat MySQL on board - Postgre leider nicht. Aber auch das kann man über eine Middle-Ware Schicht wie z.B. Sequoia realisieren. Bei meiner Diplomarbeit habe ich meine Empfehlung gemessen an Gesamtpunkten für PostgreSQL ausgesprochen(Im Test waren MS ACCESS, MySQL, PostgreSQL, Oracle , MS SQL).
Ansonsten sind beide Datenbanken wirklich sehr stabil und schnell. Grüße
Vielen Dank für die übrigen Antworten, ich werde es mir mal ansehen.
Postgresql laeuft zudem sehr stabil, ist in Sachen SQL sehr restriktiv (man kann keinen Varchar in ein Numberfeld stecken), bietet Transaktionssicherheit auch ueber DDL-Befehle hinweg ...
Das ist aber noch nicht alles, schau einfach mal auf
http://www.postgres.de/features.html
http://wiki.postgresql.org/wiki/FAQ/de
Ich wuerde dir empfehlen, es einfach mal zu installieren und auszutesten. Denn all die Sachen bringen nix, wenn man sich an die Ungereimtheiten von MySQL gewoehnt hat und sie nicht mehr ablegen will, wie zum Beispiel die ``.
Leider kommt phppgadmin nicht an phpmyadmin heran und PgAdmin III ist auch keine große Leuchte...
Allerdings sollte man mit Aussagen wie "Insgesamt ist der Funktionsumfang bei Postgres größer" vorsichtig sein. MySQL entwickelt sich schnell weiter, soetwas gilt in vielen fällen oft nicht mehr lange.
Zudem sollte man MySQL immer passend zur Aufgabe betrachten, immerhin kann MySQL vieles sein, von reinem Highspeed Readonly Datenlieferanten, bis zur verlässlichen zentralen Firmen-DB. Das erfordert teils aber deutlich andere herangehensweisen an die DB, ihre Einstellungen und die Wahl der Tabellentypen.
Pauschale Aussagen sind da immer etwas schwer. MySQL kann schneller sein als PostgreSql, oder langsamer. MySQL hat Funktionen besser integriert, andere schlechter. Manches ist simpler, aber brauchbarer. Es kommt immer darauf an was man machen möchte.
"In vielen Fällen" macht die Sache deutlich ;-)
Zur Erfüllung einer aus meiner Sicht grundlegenden Anforderung für Datenbanken hat's sehr lange gebraucht.
http://de.wikipedia.org/wiki/ACID
Zudem sollte man MySQL immer passend zur Aufgabe betrachten, immerhin kann MySQL vieles sein, von reinem Highspeed Readonly Datenlieferanten, bis zur verlässlichen zentralen Firmen-DB.
Ob PostgreSQL auch beim einfachsten Andwendungsfall immer noch nennenswert langsamer ist, vermag ich nicht zu beurteilen. Zu PostgreSQLs 6er-Zeiten war MySQL dabei erheblich schneller. Bei komplexeren Abfragen und zunehmender Anzahl der Clients brach MySQL völlig ein, während PostgreSQL durchstampfte. Wobei PostgreSQL schon damals Abfragen erlaubte, für deren Ermöglichung MySQL noch einige Jahre brauchte.
Zur "verlässlichen zentralen Firmen-DB": gerade für diesen Anwendungsfall traue ich PostgreSQL mehr zu. Schon damals war es möglich, die Anwendungslogik in die Datenbank zu verlegen.
Wieso sollte man ein System nutzen, welches hinsichtlich der Funktionalität aufschließen mußte? Und lange übelste "Gotchas" aufwies?
Einschränkung: bzgl. Cluster und Replikation steht MySQL nach meiner Kenntnis besser dar.
Das erfordert teils aber deutlich andere herangehensweisen an die DB, ihre Einstellungen und die Wahl der Tabellentypen.
Das Problem der verschiedenen Backends, die mal dieses, aber nicht jenes können, stellt sich bei PostgreSQL nicht.
Pauschale Aussagen sind da immer etwas schwer.
Sehe ich anders. PostgreSQL ist mächtiger. Auch wenn MySQL z.B. inzwischen Trigger kennt, entnehme ich der aktuellen MySQL-Dokumentation, dass bei PostgreSQL damit mehr möglich ist.
Manches ist simpler, aber brauchbarer.
Verstehe ich nicht. Ein Beispiel?
Es kommt immer darauf an was man machen möchte.
Sicher reicht MySQL für vieles ;-)
PS: als Client reich(t)en mir unter beiden Systemen meist die jeweiligen Konsolen. PgAdminIII ist aber ein sehr schönes Tool, um z.B. Trigger und Funktionen zu bearbeiten. Scheint mir tiefer zu liegen, als PHP-Oberflächen.
Ich für meinen Teil finde die MySQL Tools irgendwie verwirrend, warum mehrere Tools. Mit PgAdmin 3 hat man ein ganz einfaches leistungsfähiges Tool zur Wartung und Performance Analyse/Optimierung. Die Frage ist was macht man denn groß mit solchen Tools, Backups werden meist über Scripte gefahren, User legt man selten an. Tabellen ändert man in der Regel nicht. Das einzige was ich mit so einem Tool mache ist mal nen Index anlegen, ein paar SQL Abfragen zu tätigen etc. da ist mir das einfache PgAdmin viel lieber, die Usability von MySQL Admin bzw Query Browser finde ich nicht so prickelnd.
Um ein DB Schema zu entwickeln kannst du weder die MYSQL noch die PostgreSQL Tools brauchen, da braucht man dann sowas wie Toad.
Den Punkt vergaß ich. Die graphische Ausgabe von "Analyse" ist hervorragend. Zeigt deutlich die zu optimierenden Knackpunkte einer Abfrage.
Das liegt daran, das MySQL für die gleiche Aufgabe mehr CPU Zyklen braucht als postgresql, was an den Kontextumschaltungen zwischen den inzwischen Dreiundsechzig(?) verschiedneen Backends liegt, was wiederum zum einen den Lüfter anschmeißt und zum anderen aufgrung heißgelaufener CPU diesen MySQL typischen Geruch von verbranntem Silikon erzeugt, den man sonst nur von pupertierenden Vista besessenen Egoshooterspielern kennt.
Ich hab bisher noch keine ERP Umgebung gesehen in der Postgres gelaufen ist, erp Systeme sind ja oftmals konstenpflichtige Systeme, bei denen man in der Regel immer eine kostenpflichtige mit Enterprise Support erhältliche DB nutzt.
Offensichtlich hast du sehr bis sehr sehr wenig Ahnung.
Postgres wird z.B. sehr gern dort eingesetzt wo es um Geolocation geht oder um sehr große DBs. Ich entwickle zur Zeit eine Anwendung, bei der sich bis zu 50Mio Datensätze in der DB befinden (das Schema hat ca 30 Tabellen mit je 5-15 Feldern, läuft auf nem Quad Xeon mit 4GB RAM und nem Raid5 aus SAS Platten), Postgres macht dabei eine ausgezeichnete Figur vor allem weil es automatisch die Abfragen analysiert und danach selbst optimiert, autovaccum lässt sich nach dem eigenen Bedürfnissen konfigurieren etc.
Wenn ich mal zuviel Zeit habe möchte ich mit den Daten mal einen Benchmark machen, wäre schon interressant wie sich MySQL bei so einer DB Größe schlägt.
Offensichtlich hast du sehr bis sehr sehr wenig Ahnung.
Naja, eine Art KMU-ERP im weiteren Sinne habe ich mal erstellt. pl/R sei gedankt. Kam bei der Kreditversicherungen gut an, sowas hätten sie noch nicht gesehen.
Postgres wird z.B. sehr gern dort eingesetzt wo es um Geolocation geht oder um sehr große DBs.
Der Umgang mit geographischen Daten dürfte eine Stärke von PostgreSQL sein.
Wenn ich mal zuviel Zeit habe möchte ich mit den Daten mal einen Benchmark machen, wäre schon interressant wie sich MySQL bei so einer DB Größe schlägt.
Aber abseits der Größe bitte mit dem richtigen Backend für Geodaten. SCNR
Oh, und Enterprise Support für PostgreSQL existiert.
Wieviel Ahnung ich von dieser Materie habe, kannst du kaum beurteilen.
Oh, ich sehe greade: du entwickelst eine Anwendung mit einem so wahnsinnig komplexen Schema mit ca. 30 Tabellen. 50Mio Datensätze, Maschinen mit 4GB RAM. Und findest das Aufregend. Natürlich bist DU der König aller Datenbankanwendungen.
Hast du JEMALS ein "echtes" ERP auch nur aus Distanz gesehen? Eher nicht, oder?
Hihi, der war echt gut.
Bei solchen Datenmengen reicht normalerweiser SQLite, wenn nicht parallel beschrieben wird.
(Für Prototypen oder Single-User-Anwendungen finde ich ist SQLite unglaublich gut, was Funktionsumfang und Effizienz angeht.)
Replikation/ Clusterfähigkeit:
Das kenn ich nur vom Lesen, aber ich habe recht viele Einschränkungen bei MySQL gesehen, bei PostgreSQL gibt es eine Vielzahl von Lösungen, die anscheinend recht reif sind.
Facebook und Skype benutzen IMHO PostgreSQL.
Jochen
LOL. Ich lach mich gerade tot. Die Anwendung die ich jetzt als Webanwendung realisiere war zuvor mal als Single User Python Anwendung mit SQLite realisiert, die Performance war dabei bei 100 000 Datensätzen schon unterirdisch schlecht.
Das Problem an meiner Anwendung ist nämlich, dass ich nicht wie bei Spielzeuganwendungen mal schnelle den Inhalt des letzten Eintrags auslese, sondern z.B. Distincts über ein paar Millionen Tupel mit Strings laufen lassen muss.
Genau, bei solchen Fällen würde ich auch kein SQLite empfehlen ;-)
10^8 Datensätze recht fix zu verarbeiten, schafft SQLite allerdings, wenn die queries nicht zu komplex sind.
Und das find ich schon beachtlich.
Ich hab auch schon Anwendungen für MySQL Cluster (mehrere Master und 150 Slave Server) entwickelt, diese Anwendungen stellten aber keine große technische Anforderungen an die DB, da mussten halt nur täglich 100Mio User bedient werden, mit ganz einfachen Selects.
Das Projekt hier ist anders, geringe Userzahlen aber komplexe Abfragen mit sehr großen Ergebnismengen. Hier bringt mir z.B. ein MySQL Cluster gar nichts.
Dann sag mir doch mal welches Spielzeug ERP denn Postgres benutzt.
>>Hast du JEMALS ein "echtes" ERP auch nur aus Distanz gesehen? Eher nicht, oder?
Ich benutze eins jeden Tag um meine Stunden zu buchen--> SAP
Da du offensichtlich schon PostgreSQL in Verbindung mit ERP Systemen gesehen hast, scheinst du wohl im Bereich 5 Mann Betriebe tätig zu sein.
Meine Kritik wendete sich an die Anbieter von ERP Standardsoftware, die zwar wohl wissen (zumindest die Techniker) das ihr Produkt wunderbar mit PostgreSQL harmoniert, aber es leider nicht schaffen, dies auch ihren Marketing- und Vertriebsleuten beizubringen. Die kennen halt DB2, Oracle und Informix (oh, und natürlich MaxDB, aber das unterstützt aus verständlichen Gründen nur der ERP Marktführer) . Und wenn der Interessent nach der freien (wobei frei hier natürlich "..as in Beer", nicht "..as in Speech" bedeutet, die Einführung eines ERP-Systems hat meist einen kommerziellen, selten einen idiologischen Hintergrund...
) Datenbank frägt, gibts halt ein reflexartiges "MySQL". Liegt natürlich daran, daß hinter MySQL eine Firma mit kommerziellen Interessen steht und damit auch Marketing betreibt, und PostgreSQL eine Community-Entwicklung mit einer akademischen Historie. Da gibts keinen Vertrieb, kein Marketing, kein Markenbranding.
Und nein, mit 5 Mann Klitschen hab ich nichts zu tun.
Man muss aber auch eingestehen, dass PostgreSQL auch seine Defizite hat und daher nicht einfach immer empfehlenswert ist. Im Bereich Replikation ist Pg noch nicht da wo die Konkurrenz ist und gerade bei großen verteilten Projekten wäre das schon wichtig, da merkt man halt noch wo PostgreSQL seinen Ursprung hat:-)
Für (richtig) grosse, verteilte (synchrone) Systeme ist PostgreSQL derzeit das falsche Werkzeug, ganz klar.
ich erinnere mich an den Film 'Der Flug des Phoenix". Hardy Krüger baut dort aus einem Wrack eine einmotorige Maschine. Als es herauskommt, dass er nur Flugzeugmodelle konstruiert und keine richtige große Flugzeuge, sind die Leute schockiert. Hardy kann es auch nicht fassen, dass die Leute den Modellflugzeugbau so gering schätzen und erklärt:
'aber Modellflugzeuge sind viel schwerer zu bauen als große Maschinen, die fliegen fasst von selbst'.
Ja, in der Tat, die Überheblichkeit der Leute, die schon SAP gesehen haben kotzt mich manchmal an.
Komischerweise kommen solche Aussagen immer von Leuten, die SAP maximal aus Anwendersicht kennen.
Meine persönliche Empfehlung: Erweitere deinen Horizont, bevor du solche Aussagen machst. Es gibt genug Möglichkeiten dazu. Selbst beim Hersteller. goto http://help.sap.com
Aha, das ist ja interessant, woher weißt du, dass diese Aussagen _immer_ von solchen Leuten kommen?
Ich möchte darauf gar nicht tiefer eingehen, aber in einem hast du recht: Die SAP-Leute halten eng zusammen, können meist nicht viel aber verdienen Kohle ohne Ende. Bewundernswert. Sie halten den Stöpsel auf "ihrem hochwichtigen" System als Blackbox drauf und machen einen Riesentrara drum, so dass die Kohle in Größenordnungen ohne große Nachfragen fließt und kaum jemals wer nach Kosten-Nutzen fragt. Wirklich bewundernswert. Könnten sich viele andere IT-Bereiche ne Scheibe von abschneiden. Kenn ich sonst nur noch von Oracle-"Gurus" so.
Im Ernst: Ich kann meine Aussage nur noch mal wiederholen: Mach dich erst mal schlau, was SAP ist, wie es funktioniert, was da alles dranhängt. Die Doku ist für jeden frei einsehbar (und das ist keineswegs selbstverständlich in der Branche!). Du kannst dir auch einen voll funktionsfähigen Netweaver runterladen und für einige Zeit testen. Das ist zwar "nur" die technologische Basis ohne ERP Komponenten, aber zum reinschüffeln in ABAP etc. locker ausreichend.
Oh ja: es gibt auch in der SAP-Beratungsbranche "Blender" (= Grosse Klappe, nix dahinter). Aber meiner Erfahrung nach nicht mehr, wie in anderen IT-affinen Branchen. Und die kommen entweder nicht weit (weil ihr fehlendes KnowHow schnell sichtbar wird) und schulen um zum Vorwerk Vertreter oder so weit, daß man mit ihnen nichts mehr zu tun hat (AKA Befördert).
Die Anforderungen eines "5 Mann Betriebes" (sagen wir mal Handwerksmeister, 3 Gesellen, 1 Lehrling) sind halt wesentlich geringer und komplett anders ein kleinerer mittelständischer Betrieb mit 250 Leuten. Da kann man nicht einfach hochskalieren.
ich habe beide Systeme benutzt, sowohl auf Software Ebene als auch auf der Datenbank Ebene.
Nutzt man Persistenz Schichten in Java z.B. wie Hibernate oder Toplink (siehe JPA) sind zahlreiche Features der Datenkbanken nicht wirklich relevant.
Fachlogik hat nichts in DB zu suchen - zu teure Folgekosten bei Pflege.
In Punkto Geschwindigkeit ist meiner Erfahrung nach MySQL leicht vorne - da hält keine andere DB mit, in Punkto Stabilität ist PostGreSQL denke ich die bessere Wahl.
Replikation, Clustering usw. hat MySQL on board - Postgre leider nicht. Aber auch das kann man über eine Middle-Ware Schicht wie z.B. Sequoia realisieren.
Bei meiner Diplomarbeit habe ich meine Empfehlung gemessen an Gesamtpunkten für PostgreSQL ausgesprochen(Im Test waren MS ACCESS, MySQL, PostgreSQL, Oracle , MS SQL).
Ansonsten sind beide Datenbanken wirklich sehr stabil und schnell.
Grüße