Rico Koerner <[email protected]> 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 -- Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect. (Linus Torvalds) "If I was god, I would recompile penguin with --enable-fly." (unknown) Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889° _______________________________________________ Lug-dd maillist - [email protected] https://ssl.schlittermann.de/mailman/listinfo/lug-dd
