Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Oracle vs. MySQL
Hey, da mir mal wieder was in der NG zu Ohren (Augen) gekommen ist, das Oracle nicht kann, und MySQL schon, draengt sich mir langsam aber sicher die Frage auf: Warum Oracle? Ich mein, wenn MySQL mit den Views, Stored Procedures, Subqueries - also kurz mit der Version 5 fertig ist, kann Oracle doch einpacken, oder?? Ist das mit anderen ‘grossen’ DBMS genauso? Vielleicht kann mich ja einer davon ueberzeugen, dass Oracle doch besser ist…
MySQL-Vorteile bis jetzt:
- Kann LIMIT (erspart einem IMO jede Menge JOIN-Arbeit!)
- Kann mehrere Tabellen Updaten (UPDATE t1, t2…)
- Kann beliebige arithmetische Ausdruecke berechnen (SELECT ohne FROM, wer’s braucht)
- Bietet ne anstaendige Doku auf der Webseite
Wenn ich hier bei irgendwas Mist erzaehle, korrigiert mich bitte. 
Naja, die Vorteile liegen imho v.a. darin, dass man z.B. während dem Betrieb konsistente Backups machen kann ohne die DB anzuhalten.
Imho kann man Oracle-DBs auch zu Clustern zusammenschalten (wie auch immer).
Ich bezweifle vor allem dass es irgendetwas gibt, das MySQL kann, Oracle aber nicht (auch wenn die Syntax anders sein mag). Die von Dir genannten Einschränkungen dürfen wir nicht verwenden. Das sagt nichts darüber aus, dass Oracle das nicht kann - vielleicht müssen ja spezielle Modis eingeschaltet werden.
Ich glaube auch, dass wir aus unseren beschränkten Erfahrungen wirklich auf die Leistungsfähigkeit von Oracle schliessen können. Wie z.B. sollten wir den Optimizer bewerten?
Hi
MySQL kann auch Clustering.
Der Unterschied zwischen MySQL und Oracle ist nicht in den SQL-Dialekten zu suchen.
Die Query-Möglichkeiten, die du anführst, hauen mich jetzt nicht um, auch wenn ich selbst gerne auf LIMIT zurückgreife…
Und die Dokumentation von Oracle ist sicherlich umfangreicher, auch wenn sie nicht frei für jeden zugänglich ist.
Eher ist es so, dass MySQL erst im Erwachsenwerden ist. Bis vor kurzem noch wurde es müde belächelt und das teilweise zurecht. MySQL ist zwar relativ schnell, aber das vor allem, weil es nix kann[tm].
Natürlich hat sich das geändert bzw. die MySQL-Entwickler sind stetig dabei, das zu ändern. Aber in der heutzutage noch weitläufig eingesetzten Version 3 kann MySQL noch nicht mal Subquerys…
MySQL muss sich erstmal überhaupt in die Liga der großen Datenbanken begeben, bevor man es einfach so vergleichen kann.
Bei einer großen Datenbank kann es schon mal passieren, dass Querys tagelang in Bearbeitung sind. Und das ist normal, bzw. hinzunehmen.
Diese Leute würden schlichtweg noch gar nicht auf die Idee kommen, MySQL einzusetzen.
Aber mal sehen, was die Zukunft bringt.
cu
Ford Prefect
tagelang???
tagelang.
ich hatte eigentlich auf ein beispiel gehofft 
des ist einfach die Fuelle von ‘kleinen’ Faehigkeiten wie online backups, transactions … die einzeln betrachtet gar net so schwer zu implementieren aussehen, aber in ihrer Summe alles andere als trivial sind.
Was haben tagelange queries fuer eine Aussage ueber die Qualität einer Datenbank? Wenn die Menge an Daten so fett ist, dann ist des doch logisch. Wobei mir grad der Gedanke kommt, was passiert, wenn sich die Daten währenddessen ändern und dann ein backup gemacht wird oder schlimmer teilweise zurückgespielt wird, hmm doch net so trivial.
Ein Beispiel dafür? Rasterfandung vielleicht.
Ich denk mal, dass so tagelange Abfragen schon irgendwie koordiniert werden müssen, und in der Zeit halt keine Änderungen und kein Backup gemacht werden sollten. Kann das aber freilich net beurteilen.
Naja, MySQL 4.1 soll wohl im Herbst ‘fertig’ werden, dann schauen wir mal, was die Zukunft noch so bringt.
Wenn die tagelange Abfrage nur lesend ist (Statistiken), dann kann man durchaus Änderungen zulassen - man muss halt entsprechende Kopien bereitstellen, an denen gearbeitet wird.
Was haben tagelange queries fuer eine Aussage ueber die Qualität einer Datenbank?
Die Frage ist, ob man in solchen Umgebungen MySQL überhaupt vernünftig einsetzen könnte.
BTW konsistentes Backup ohne die Datenbank anzuhalten geht doch problemlos mit einem SQL Dump.
Evtl. sind zusammenhängende Tabellen zu locken, aber das liese sich so oder so nicht vermeiden.
Ein SQL-Dump ist transaktionskonsistent? (Ehrliche Frage, ich weiss es nicht).
Und eben das sollte ein DB-System automatisch machen. Und zwar ohne gleich komplette Tabellen zu locken.
SQL-Dumps können doch selbst in Transaktionen verpackt werden…
Das wirft nämlich dann auch die frage auf, ob mySQL nicht bei großen Datenmengen einfach kollabiert. Ein Walmart SAP Business Warehouse auf mySQL kann ich mir (ohne dass das durch Fakten gedeckt wäre) einfach nicht vorstellen.
Nachdem ihr Euch ja anscheinend gut auskennt mit MySQL:
Bin grad ein wenig am einarbeiten:
Kann es sein, dass MySQL keine Fremdschlüsseleigenschaft kennt?
Wär ja echt schade.
Wenn doch - wie gehts?
Nicht mit MyISAM-Tabellen. AFAIK geht das bislang nur mit InnoDB-Tabellen.
Probiert doch mal PostgreSQL oder Firefox (aka Interbase) oder MaxDB (aka SAPDB aka Adabas).
Besonders die letzteren spielen durchaus in der gleichen Klasse wie Oracle.
Firefox? Meinst du dieses Firebird, weswegen der Browser umbenannt wurde? Oder gibt’s jetzt auch 2 Firefoxe?
Firebird natürlich. Sorry.