Am 23.07.2011 15:57, schrieb Andreas Kretschmer: > Rico Koerner <[email protected]> wrote: > > Ja, ich kenne die Argumentationen, z.B. aus früheren MySQL-Dokus, gegen > Transaktionen und referentielle Integrität und so. Nur bin ich der > Meinung, wenn die die Wahl zwischen zwei Systemen hat, wovon eines nix > kann und das andere viele Dinge, die man von ref. Datenbanken ganz > einfach erwartet, einfach gut kann, dann ist die Entscheidung eigentlich > logisch.
Ich will hier keinen Glaubenskrieg vom Zaun brechen, aber warum soll ich mit dem LKW zum einkaufen fahren, wenns auch in den Rucksack paßt. Wenn ich die vielen Dinge nicht brauch, sind sie meist nur Ballast. > Und Transaktionen sind ein wirklich feines Ding, insbesondere wenn man > diese auch bei DDL hat. Wie gesagt, wenn man sie braucht. Bei mysql muß das in die Application wandern. Da find ich die in der DB schon passender. > 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. > 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. > 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. > die bei uns laufen. Plötzlich wächst das System. Plötzlich will man z.B. Ja, das Wachstum ist meistens das Problem. Oder besser gesagt, die Weitsicht bei der Entwicklung. Irgendwann muß man den Rucksack dann doch eintauschen. ;-) > Replikation haben. Leider knallt die z.B. bei MyISAM schon dann, wenn > auf dem Master eine Abfrage mal schief geht. Peng. Und wenn das Backup Gut zu wissen, daß die Replikation problematisch ist. > 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. Bei der Größe ist an der Backupstrategie etwas falsch. LOCK -> Snapshot -> Backup Damit sollte die Downtime nur wenige Sekunden. Klar, wenn die Datenbank solche Mechanismen eingebaut hat, ist das auf jeden Fall besser. >> 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. :-( > 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. ;-) Womit wir wieder an dem Punkt ankommen, daß es vom Anwendungszweck abhängt, welche DB mehr/weniger Vor- und Nachteile hat. Rico
smime.p7s
Description: S/MIME Kryptografische Unterschrift
_______________________________________________ Lug-dd maillist - [email protected] https://ssl.schlittermann.de/mailman/listinfo/lug-dd
