MySQL; PostgreSQL; MSSQL

Colttt

Enthusiast
Thread Starter
Mitglied seit
16.01.2006
Beiträge
2.664
Ort
Brandenburg(stadt)
Ähm wo liegen die unterschiede/ vor- und nachteile, bzw was sollte man nehmen? Ich kenn nen programmierer der schreibt nur für MSSQL weil er sagt das die anderen nicht so gut, perfomant, stabil und funktionskräftig sind wie MSSQL, stimmt das?? denn 2500€ für ne DB find ich nen bissl happig wenn es doch kostenlose gibt und SQL ist SQL ist doch nen festgelegter Standard und da sich daran doch eigentlich alle halten sollten ist es doch fast wurst was davor steht, oder seh ich das was falsch?

Ich weiss auch das MySQL die meinstbenutzte DB der Welt ist, dann kann ja die nicht soo schlecht sein bzw warum nutzen dann die anderen überhaupt MSSQL??

Schonmal besten dank für eure hilfe.. :wink:

ähm was benutzt ihr denn und warum??
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
wo die unterschiede im einzelnen liegen kann ich dir nicht sagen^^
kommt halt drauf für was du die datenbank benutzen willst, also wieviel abfragen usw bewältigt werden müssen..
ich selber habe 2 root server wo verschiedene webseiten drauf laufen und benutze standartmäsig mysql, ist erstens kostenlos und habe damit auch noch keine schlechten erfahrungen gemacht bzw was schelchtes gehört.


mfg
 
Ok , überlegen wir mal ...

Kostenlos ? MySQL
Wird von den meisten menschen weiterentwickelt ? MySQL
ist OpenSource ? MySQL

Resulatat : Wenn viele menschen an einem projekt arbeiten (mehrere Tausend locker)
wird ein projkt bzw das produkt aus dem projekt natürlich besser als wenn ein paar huntert daran arbeiten .
 
aber auch hinter mysql steht eine firma, ist die frage wie sehr open source das noch ist. klar ist der source offen, aber einfach so mitarbeiten ist auch nicht so einfach.

was willst du denn machen, das ist ja das wichtige. vielleich auch mal andere systeme/konzepte als relationale datenbank ins auge fassen.

Von den dreien wuerde ich mysql waehlen. einfach nur weil ich da am meisten erfahrung mit habe.
 
SQL an sich ist ja standardisiert; denke mal auch nicht, dass du eine Uralt-Version von einem RDBMS nimmst, da es hier ja auch Unterschiede gibt (Stichworte SQL89, SQL92 etc).

Einer der Unterschiede liegt am System an sich. Wie es intern die Daten verwaltet, wie gut seine Ausfallsicherheiten u.ä. sind (abgebrochene Transaktion und Rollback, Interventionen etc.), wie gut die Skalierbarkeit ist (Geschwindigkeit, große Datenmengen, Durchsatz) und sonstige betriebsbedingte Parameter.

Das zweite Wichtige sind die herstellerspezifischen Extras - und da liegt der eigentliche Knackpunkt. Ein 0815-User dem reicht da locker die Free-Edition von mysql oder postgres (oder ähnlichen Vertretern)..

Wenn du dir mal genauer die Featurelisten von der mysql PRO, Oracle oder MSSQL anschaust wirst du die Unterschiede sicher selbst erkennen.

Noch etwas was du bei so Free-Editionen (meist) nicht hast: Direkter Support vom Hersteller und ich mein jetzt nicht Mailingliste bei denen du erstmal Tage auf Antwort warten kannst.

War jetzt nur mal so kleiner Schnippsel, aber ich denke der reicht ;)
 
Kann dem Vorposter nur zustimmen.

SQL an sich ist zwar an Standard, aber gerade die großen Hersteller wie IBM, Oracle oder Microsoft modifizieren diesen schon sehr arg. (Z.B. haben Standarddatentypen wie sie in SQL verankert sind in Oracle eine ganz andere Bedeutung als z.B. in MSSQL oder IBM...).

Aber der größte Unterschied zwischen MySQL (Hersteller ist übrigens Sun Microsystems, dementsprechend vllt. bald Oracle) und anderen proprietären Systemen liegt an der Verwaltung der Daten. Während IBM, Oracle und MSSQL ein einheitliches System haben, kannst du bei MySQL zwischen glaub 7 oder 8 unterschiedlichen Speichersystemen wählen. Und jedes Speichersystem hat seinen individuellen Stärken. Dabei gibt es Systeme wie schnell die Datenbank durchsuchen können und allgemein schneller sind als andere, was aber zulasten der Sicherheit (Transaktionen und Rollback) läuft. Ein anderer Punkt ist wahrscheinlich, warum MySQL so häufig eingesetzt wird, der ressourcensparende Betrieb. Hatte Oracle 11g auf meinem Rechner für mein Studium und das Teil hat gefressen, wie nichts gutes. Beide Prozessoren waren im Schnitt bei 70% und der RAM war auch zu 80% gefüllt...
 
Ok und warum ist mysql beliebter als postgresql?? Wenn ich bei debian bei der Installation datenbankserver wahle dann installiert er immer postgresql..

Also ist mssql nun wirklich "besser" oder warum wollen die dafür soviel geld haben?? Ich steig da noch nicgt so rivhtig hinter..

---------- Beitrag hinzugefügt um 17:10 ---------- Vorheriger Beitrag war um 17:09 ----------

Ok und warum ist mysql beliebter als postgresql?? Wenn ich bei debian bei der Installation datenbankserver wahle dann installiert er immer postgresql..

Also ist mssql nun wirklich "besser" oder warum wollen die dafür soviel geld haben?? Ich steig da noch nicgt so rivhtig hinter..
 
warum mysql beliebter als postgres ist kann ich nicht genau sagen, aber ich glaube das haengt mit der entwicklung von php zusammen.

Ich behaupte einfach mal, dass es das MySQL PHP Modul deutlich länger gibt als das Postgresmodul. Und das ist halt eine der hauptursachen dafür das mysql so oft genutzt wird
 
ich denke mysql wird weiter verbreitet sein als postgres weil die Einstiegshuerde niedriger ist.

Ansonsten sehe ich keinen Grund warum man fuer eine Datenbank Geld ausgeben sollte, mit den entsprechenden Storage Engines kann mysql auch einiges. Und ich hab auch schon Terrabyte grosse Datenbanken gesehen die sich mit mysql flott bearbeiten liessen.

Shad0w: lass dich mal nicht von dem "2500 fuer ne Datenbank" abschrecken. Das faellt bei einem grossen Projekt auch nicht mehr ins Gewicht. Die Hardware kostet dann noch mehr. Ich weiss zufaellig dass bei einer grossen deutschen Datingplattform Hardware fuer 200.000 Euro rumsteht. Da waeren die 2.5k fuer die mssql Lizenz auch keinen mehr aufgefallen.
 
Zuletzt bearbeitet:
Vll nebenbei noch erwähnt... fasst alle unserer großkunden benutzen mysql und hier sind einige platformen bei die groß und sehr stark frequentiert sind. Ums vll mal statistisch auszudrücken... 99,99% mysql und 0,01% oracle, mssql, postgres.

Ich selbst hab mich bis jetzt nur mit mysql beschäftigt, aber laut meinen kollegen soll wohl im gegensatz zu postgres, postgres besser replizieren können...
 
Also gibts keinen grund sich rxtra mssql zu kaufen, oder??

Wir starten nämlich bald ein neues Projekt, und holen uns dafür extra nen neuen server und der Server soll auch ganz schön ackern wegen sql, und in zeiten der wirtschaftskrise find ich 2500€ nen bissl viel für etwas was es auch als opensource gibt und bis jetzt hab ich noch kein grund gesehn der für mssql und gegen postgresql bzw mysql spricht.
 
Naja, SQL ist zwar ein "Standard", aber das heißt nicht, das jede Software auf jeder DB läuft. Wenn man eine Software kauft, sind die unterstützten DBs immer aufgeführt (und häufig ja auch ein kauf-Kriterium bzw. nicht-kaufen-Kriterium). Wenn bei einem neuen System nur MSSQL steht, wirst man wohl nicht drum rum kommen eine MSSQL-DB zu kaufen/installieren.

Viele Statements kann man nicht 1:1 von MySQL nehmen und die funktionieren dann auch unter Oracle, MSSQL, Postgres. Fast immer sind da Anpassungen notwendig...

Aber wenn ihr ein eigenes Software-Projekt startet, ist es ja euch (und eurer ERFAHRUNG) überlassen, welche DB ihr als Grundlage nehmen wollt.

Gruß

edit:
Das MySQL so verbreitet ist, hat andere Gründe als das die "Einstiegshürde" so niedrig ist. Früher lag MySQL direkt PHP bei, das war der Grund. Heute ist das nicht mehr so.
Übrigens, wenn man Hardware für 200.000€ kauft, hat man in der Regel vor, ein Clustersystem zu bauen. Dann kommt man aber mit einer kleinen MSSQL-Version für 2.500€ nicht mehr aus. Das dürfte deutlich teurer sein.

Wir haben selbst ein Oracle Cluster System, die Software-Lizenz kostet (CPU-bezogen) über 20.000€...
 
Zuletzt bearbeitet:
Man muss sich schlicht mal vor Augen halten, was an Mengen von CMS gibt, die auf MySQL bauen. Daraus folgt, dass einfach die Nachfrage der Masse nach MySQL am größten ist, und die allermeißten ISPs nun mal MySQL immer im Angebot haben. PostgreSQL wird dann schon ein wenig spezieller, meißt sich das dann aber auch Projekte, bei denen man nicht mehr mit nem 5€ Webhostingpaket auskommt.

Ich habe Anfang des Jahres ein PostgreSQL für nen Kunden installiert, der eine Replikation wünschte. Nach ner Woche testen und fummeln war mir klar, dass der Markt nix hergibt, was für ne Standby-Repli wirklich taugt und nicht übermäßig kompliziert ist.

Bei MySQL bastel ich dir Master <-> Master -> Slaves * N, Master -> Slave Replis, verteiltes Lesen, whatever, binnen nem halben Arbeitstag, inklusive des Restsystems. Es ist relativ einfach aufzusetzen, gut zu überwachen und die Ausfallszenarien lassen sich gut abdecken, nen Worst-Case Restore ist auch noch überschaubar. All das war bei PostgreSQL nicht wirklich gegeben.

Dafür bietet PostgreSQL gerade in der aktuellen 8.4er Version einige wirklich interessante Dinge.

Fazit: die Menge verlangt MySQL, also richtet sich der Markt daran aus.

Wer anderes braucht. ist Big- oder Globalplayer und hat schon mächtigere Anwendungen dahinter stehen.
 
Bei MySQL bastel ich dir Master <-> Master -> Slaves * N, Master -> Slave Replis, verteiltes Lesen, whatever, binnen nem halben Arbeitstag, inklusive des Restsystems. Es ist relativ einfach aufzusetzen, gut zu überwachen und die Ausfallszenarien lassen sich gut abdecken, nen Worst-Case Restore ist auch noch überschaubar. All das war bei PostgreSQL nicht wirklich gegeben.

ich muss ehrlich zugeben, dass ich noch nie mit postgres gearbeitet habe und mich immer vor gestreubt habe, aber laut meinen kollegen soll replikation und wiederherstellung im fehlerfall bei postgres wohl deutlich besser gehen.

Bei MySQL jedoch ist es bei mir nicht anders mit der Replikation. Probleme seh ich nur immer wieder dann, wenn bei ner großen daten bank mit sehr vielen "indexen" (oder wie es auch heißt), einträgen etc. einen der master, slave wegen festplatten problem oder sonst etwas um die ohren fliegt.
Man nehme einfach mal an, man hat einen kunden der eine Datenbank hat welche um die ~20gb groß ist und hoch frequentiert ist.
Ob nun Master oder Slave weg fliegt ist prinzipiell egal, da man im falle das der master weg ist, halt den slave zum master macht. Das eigentlich Problem ist jedoch, die wiederherstellung des defekten Servers. Denn hier muss ein Dump erstellt werden und das mit einem write lock auf die laufende Datenbank. Für manche Kunden wäre soetwas fatal, wenn der die DB für 2h nicht beschreibbar ist. Ebenso die wieder Herstellung... bei einer 20GB Datenbank kann man teilweise schon davon ausgehen, dass die Wiederherstellung nen paar stunden dauert und das find ich teilweise nicht praktikabel :/

Gut es gibt noch die "Evil Method". Die wäre dann DB kurz anhalten, db binarys kopieren, db starten und die binarys per rsync rüberschaufeln. aber sowas macht man nicht! :shot:

Und es gibt noch eine Möglichkeit, und die wäre "LOAD DATA FROM MASTER" erfordert jedoch bin logs wie sand am mehr bei ner datenbank mit vielen schreibzugriffen.

@ Prinzen Rolle ich würd gern mal deine Meinung dazu hören :) vll kann man ja noch was lernen

MfG
Alex
 
Je nach Datenbankgröße wird das Rückspielen natürlich unschön, das ist klar.

Wie gesagt ist das Monitoring der Repli kein Akt, und wenn man schnell genug ist und die Position hat, bei der der Slave ausgestiegen ist, kann man problemlos das Bin-Log durchflitzen lassen.

Problematisch wirds bei richtig großen DBs. Anfang letzter Woche Fehler in ner Repli, DB-Größe > 80GB, verteilt auf mehrere DBs, machts aber nicht besser. Erschwerend hinzu kam dass das System an sich nie für die Datenmenge ausgelegt und geplant war, lange Rede, kurzer Sinn, Platte voll, einzige mögliche Lösung -> Bin-Logs löschen.

Da bleibt nicht mehr viel über als MySQL anhalten, rsync anwerfen. Alternativ den Kunden bitten, alle Schreibzugriffe zu vermeiden.

Wenn du mehrere Slaves hast, auf die die Lesezugriffe verteilt werden, kannst du auch einen mal abklemmen wenn nix los ist und mit dessen Datenbestand den ausgefallenen Server wieder herstellen.

Im Endeffekt kommts immer auf die Applikation und den Kunden an, der dahinter steht. Kann man an sich nicht pauschalisieren, den größten Fehler den man machen kann ist eben, die Replikation nicht zu monitoren.
 
gut monitoring betreiben wir eh ;) replication run und seconds behindmaster checks laufen da :d

ich hab ja überlegt ob ich nicht mal mit dem ndb cluster rum spielen soll... aber irgendwie überzeugt mich das ding noch nicht ganz..
 
ok, bin zwar nicht wirklich schlauer, aber es gibt keinen wirklichen grund 2500€ für MSSQL auszugeben..
 
Die hochpreisigen Hersteller zeichnen sich erst mit Neunen nach dem Komma bei der Verfügbarkeit aus. Bei MySQL zahlst du doch auch wenn du Support haben willst.
 
zb 99.99% Verfuegbarkeit gegenueber 99.9%... das ist eine 9 mehr
 
@Nascar:

Was mich im moment wirklich interessiert ist DRDB, im Prinzip würde das den ganzen Replikationsquatsch erschlagen und du hättest immer einen kosistenten Datenbestand auf den Slaves. Ich weiß nur von den letzten Test, damals mit NFS, das das ganz dolle schief ging.

Macht natürlich nur Sinn, wenn es ne Master -> N* Slaves Repli ist mit verteiltem Lesen.

Wenn DRDB mal im Kernel drin ist und nicht mehr als FUSE läuft werd ichs denk ich mal testen. Alternativ kann man das halt auch per Fibre-Channel lösen, nur ungleich teurer.
 
Ähm wo liegen die unterschiede/ vor- und nachteile, bzw was sollte man nehmen? Ich kenn nen programmierer der schreibt nur für MSSQL weil er sagt das die anderen nicht so gut, perfomant, stabil und funktionskräftig sind wie MSSQL, stimmt das?? denn 2500€ für ne DB find ich nen bissl happig wenn es doch kostenlose gibt und SQL ist SQL ist doch nen festgelegter Standard und da sich daran doch eigentlich alle halten sollten ist es doch fast wurst was davor steht, oder seh ich das was falsch?

Ich weiss auch das MySQL die meinstbenutzte DB der Welt ist, dann kann ja die nicht soo schlecht sein bzw warum nutzen dann die anderen überhaupt MSSQL??

Schonmal besten dank für eure hilfe.. :wink:

ähm was benutzt ihr denn und warum??

Ich brech ab, zu geil. Der Typ ist hat recht wenig Ahnung von den Datenbanken. Wenn der Design der Applikation madig ist, kann die Datenbank recht wenig dafür.

Was meint er mit "perfomant" und "funktionskräftig"?

Was für ein RDBMS letzendlich zum Einsatz kommt, hängt von der Anwendung ab. Für eine WebAnwendung würde ich nicht unbedingt Oracle nehmen, dafür ist es zu überladen und zu mächtig. Genau so will ich in einem Billing-System kein MS SQL sehen.

SQL an sich ist zwar an Standard, aber gerade die großen Hersteller wie IBM, Oracle oder Microsoft modifizieren diesen schon sehr arg. (Z.B. haben Standarddatentypen wie sie in SQL verankert sind in Oracle eine ganz andere Bedeutung als z.B. in MSSQL oder IBM...).

Und das ist falsch. Der Standard wird nicht angefasst, deswegen ist es auch Standard. Das, was die Hersteller machen, ist eine eigene spezifische Syntax.

Beispiel: Oracle hat keine strickte Trennung zwischen Joins und Filter, ANSI SQL hat es. In Oracle kann ich in die WHERE-Klausel sowohl Joins als auch Bedienungen reinklatschen. Glaub, bei Access war es genau so.

Hatte Oracle 11g auf meinem Rechner für mein Studium und das Teil hat gefressen, wie nichts gutes. Beide Prozessoren waren im Schnitt bei 70% und der RAM war auch zu 80% gefüllt...

Da ist aber anderes noch faul gewesen. Ich habe Oracle 10g auf meinem Laptop mit zwei Instanzen, pro Instanz ca. 700MB Speicher. Die CPUs dümpeln bei ca. 10% rum.

'cuda
 
ui da kramt aber jmd was raus.. ;)

ähm das letzte hab ich aber nicht geschriebn, da stimmt das zitat nicht..


ich hab auch schon in nem anderen forum gefragt gehabt, ist so ziemlich das selbe rausgekommen.. das mysql mehr als ausreicht und wenn man sich zwanghaft an standards(wobei mysql bis jetzt dort sehr gut aufgeholt hat) oder grössere sachen machen will, sollte man postgresql nehmen.. es gibt nicht zwanghaft einen grund MSSQL zu nehmen ausser man möchte geld loswerden(was man dann auch mir geben könnte)

ist doch so richtig die zusammenfassung oder??
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh