Rico Koerner rico@netbreaker.de wrote:
Und Transaktionen sind nicht der einzigste Vorteil von z.B. PG, da kommen noch Dinge wie RI dazu oder Features wie TRIGGER, VIEWS, procedurale Languages, rekursive Abfragen, CTE-Abfragen etc., was PG alles kann.
Trigger und Views hab ich bisher noch am meisten vermisst, für den Rest fehlte bisher die Notwendigkeit bzw. müßte ich mal überdenken, wo ich es sinnvoll einsetzen könnte.
Nun, mittels der diversen Sprachen (plpgsql, plperl, ...) kannst Du direkt in der DB weite Teile der Anwendungslogig unterbringen. Das kann u.U. schon wirklich enorme Vorteile haben. Natürlich zu Lasten der Portierbarkeit...
Und, ganz wichtig: eine super Community. Egal was Du für ein Problem hast: über die Mailinglisten bzw. IRC bekommst Du innerhalb von Minuten einen Support, der einmalig ist.
Kann auch bei mysql nicht klagen, inzwischen ist nur das Rauschen dort etwas groß geworden, aber ich vermute, das passiert jeder Software, die einsteigertauglich ist.
MySQL hat nicht einmal eine 'freie' Doku, aber okay jetzt...
Deine Meinung, es reicht ja MyISAM, vertreten viele, die MySQL verwenden. Die Resultate sind dann z.B. große Shops oder andere Seiten,
Ich bin da nicht festgefahren, ich hab PG schon als Alternative zu mysql in Betracht gezogen. Wenn es aber keine selbst entwickelte Anwendung ist, fehlt oftmals sogar die Möglichkeit zum Umstieg.
Ja, leider ist vieles auf MySQL festgelegt.
plötzlich eine Stunde läuft (weil der Shop gut läuft ...) und dann aber immer beim Backup die DB mit 500 Prozessen LOCKED voll läuft und der Shop knallt (und damit eine Stunde Umsatz weg ist), dann sitzt man in der MyISAM-Falle...
1h Backup? Ist die DB 100 GB groß? (Ich hab bei 10 GB (alle DB) mal 6 min geschafft.) Ich kann mir nicht vorstellen, welcher Shop eine solche Datenmenge benötigt oder die Anwendung ist schlecht entworfen.
Wir haben bei uns durchaus recht große Shops laufen, bei einigen kommen Jahresumsätze im mehrstelligen Millionenbereich pro Jahr zusammen. Das läuft dann auch mal gern auf HA-Clustern und so, nette Sachen.
Und fast alle Shops basieren auf einer Software, die mit M anfängt und mit agento endet. Und diese hat eine etwas krude DB-Philosophie: da wird massiv de-normalisiert... und ja: es wird die DB als Cache 'mißbraucht'. Jedenfalls - da kommen z.T. wirklich große Datenmengen zusammen. Okay, es wird da dann aber auch InnoDB verwendet. Aber manche Kunden haben auch so ihre Eigenentwicklungen, und das zu sehen ist manchmal, ähm, ernüchternd.
Bisher hat mich die Benutzerverwaltung von PG von der Verwendung abgehalten. :-(
Was genau meinst Du damit, die pg_hba.conf?
Ja, genau die. Hab grad nochmal testweise auf einer Maschine (squeeze) frisch installiert, nachdem ich mich kurz im Tutorial (Kap. 17) eingelesen hab und gesehen hab daß man anscheinend nicht zwingend für die Benutzerverwaltung in der pg_hba rumfummeln muß.
~# psql psql: FATAL: Ident authentication failed for user "root" ~# psql -U postgres psql: FATAL: Ident authentication failed for user "postgres"
Das Tutorial hilft an der Stelle auch nicht mehr weiter. :-(
Nun ja, da gibt es neben der offiziellen Doku auch noch einige andere, man muß es halt mal sich durchlesen. Ist aber nicht wirklich soo dolle komplex, finde ich.
Mich halten z.B. die Gründe hier vor der Verwendung von MySQL ab: http://sql-info.de/mysql/gotchas.html
Da gibts aber auch eine für PG. Da steht u.a. auch drin daß count(*) sehr langsam ist. Nur um mal wieder den Bezug zum ursprünglichen Thema zu finden. ;-)
Ja, das erfordert halt einen kompletten seq. scan.
Okay, ich denke, wir beenden mal den Thread nun...
Andreas