Abo
  1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › IBMs DB2 als Storage…

Irgendwie erschließt sich mir der Sinn nicht...

  1. Thema

Neues Thema Ansicht wechseln


  1. Irgendwie erschließt sich mir der Sinn nicht...

    Autor: AlexNofftz 25.04.07 - 17:05

    Irgendwie erschließt sich mir der Sinn dieser Maßnahme nicht. DB2 ist doch schon ein voll ausgereiftes DBMS, das sehr viel mehr als MySQL unterstützt. Wo man bei MySQL noch an Details von SQL99 knabbert und Dinge wie Transaktionen und Fremdschlüssel nur über den InnoDB-Umweg unterstützt, ist in DB2 schon eine ganze Reihe von SQL2003 drin.

    Falls ich also die DB2-Features benötige, kann ich doch viel einfacher direkt DB2 verwenden, anstatt diesen Umweg zu nehmen. Will ich ein schlankes und schnelles System haben, bleibe ich eben bei MySQL.

    Der einzige Grund, der mir hier einfällt wäre, dass eine bestehende Software sehr viel von MySQLs eigener Syntax anstelle von offiziellem SQL verwendet und somit nicht portierbar ist, aber das ist denke ich eher ein Problem der Programmierung und nicht des DBMS...

    Bis dann,
    Alex

  2. Re: Irgendwie erschließt sich mir der Sinn nicht...

    Autor: Putzlappen 25.04.07 - 17:26

    AlexNofftz schrieb:
    -------------------------------------------------------
    > Irgendwie erschließt sich mir der Sinn dieser
    > Maßnahme nicht. DB2 ist doch schon ein voll
    > ausgereiftes DBMS, das sehr viel mehr als MySQL
    > unterstützt. Wo man bei MySQL noch an Details von
    > SQL99 knabbert und Dinge wie Transaktionen und
    > Fremdschlüssel nur über den InnoDB-Umweg
    > unterstützt, ist in DB2 schon eine ganze Reihe von
    > SQL2003 drin.

    MySQL ab 5.0 unterstützt übrigens auch SQL 2003. Davon mal ganz abgesehen ist InnoDB kein Umweg, sondern eine ganz reguläre Option. Während andere DBMS dem Anwender halt sagen: "Friss oder stirb", kann man bei MySQL die bewußte Entscheidung zwischen Transaktionssicherheit und roher Performance treffen.

    Ich empfehle dazu folgende Lektüre:
    http://blog.koehntopp.de/archives/1349-Leben-mit-Fehlern-der-Schluessel-zum-Scaleout.html

    > Falls ich also die DB2-Features benötige, kann ich
    > doch viel einfacher direkt DB2 verwenden, anstatt
    > diesen Umweg zu nehmen. Will ich ein schlankes und
    > schnelles System haben, bleibe ich eben bei
    > MySQL.

    Nochmal, InnoDB ist kein Umweg. Ob DB2 als Storage Engine einer sein wird, wird die konkrete Implementation zeigen. DB2 als Storage Engine für MySQL zu wählen ist sicher interessant, wenn ich ohnehin schon DB2 laufen habe und meine MySQL-Anwendungen zentralisiert in der gleichen Datenbank verwalten möchte (keine Sonderlocken für Backups usw.) und/oder ich auf dem Server nur einen schlanken zusätzlichen Serverprozess haben möchte, der lediglich das SQL entgegennimmt und die Resultsets von DB2 durchreicht, anstatt eine komplett eigene Datenbank mit dem dazugehörigen zusätzlichen Ressourcenverbrauch parallel zu installieren.

    > Der einzige Grund, der mir hier einfällt wäre,
    > dass eine bestehende Software sehr viel von MySQLs
    > eigener Syntax anstelle von offiziellem SQL
    > verwendet und somit nicht portierbar ist, aber das
    > ist denke ich eher ein Problem der Programmierung
    > und nicht des DBMS...

    Nur kann es dem Kunden ja völlig egal sein, woran es im Endeffekt liegt - der will nur, daß es läuft.

  3. Re: Irgendwie erschließt sich mir der Sinn nicht...

    Autor: Void 25.04.07 - 21:21

    Putzlappen schrieb:
    -------------------------------------------------------
    > AlexNofftz schrieb:
    > --------------------------------------------------
    > MySQL ab 5.0 unterstützt übrigens auch SQL 2003.

    Ein kleines Subset von SQL 2003, keine einzige mir bekannte DB unterstützt es komplett, und die Anzahl der unterstützen Features ist bei MySQL eher noch erbärmlich klein.

    > Davon mal ganz abgesehen ist InnoDB kein Umweg,
    > sondern eine ganz reguläre Option. Während andere
    > DBMS dem Anwender halt sagen: "Friss oder stirb",
    > kann man bei MySQL die bewußte Entscheidung
    > zwischen Transaktionssicherheit und roher
    > Performance treffen.

    Unsinn. Im professionellen Datenbank Bereich kommen 80% der Performance von einem guten Queryplanner, und der ist bei MySQL derzeit noch sehr dürftig. Klar, solche Sachen wie "select x from y where z" performieren super mit MyISAM, aber Queries dieser Art sind dort eher selten. Im Webbereich stimmt dein Einwand natürlich, die Abfragen die üblicherweise dort anzutreffen sind, sind eher trivial.

    Ich hab erst vor einigen Monaten eine MySQL Anwendung migrieren müssen weil der Planner so lausig ist, und das war ein Join von grade mal 5 Tabellen. Mag sein dass man bei der MySQL-Version noch was machen könnte, interessanterweise konnten sowohl Oracle als auch Postgresql die gleiche Abfrage ohne jegliche Optimierungen oder Tricks um den Faktor 1000 schneller ausführen. Ok, Faktor 1000 ist falsch, MySQL 92 Sekunden, PostgreSQL 13 Millisekunden, möge sich jeder selbst ausrechnen wieviel das ist.

    > Nur kann es dem Kunden ja völlig egal sein, woran
    > es im Endeffekt liegt - der will nur, daß es
    > läuft.

    Nein, sollte es eigentlich nicht wenn ihm seine Daten was Wert sind. Ist aber leider so - es ist dem Kunden egal bis er damit gegen die Wand fährt.


  4. Re: Irgendwie erschließt sich mir der Sinn nicht...

    Autor: Markus42 25.04.07 - 22:49

    AlexNofftz schrieb:
    -------------------------------------------------------
    > Irgendwie erschließt sich mir der Sinn dieser
    > Maßnahme nicht. DB2 ist doch schon ein voll
    > ausgereiftes DBMS, das sehr viel mehr als MySQL
    > unterstützt.

    MySQL ist halt gerade "in".

    Wobei es wohl drei verschiedene Version von DB2 zu geben scheint (DB2 für i5/OS, z/OS und Linux/Unix/Windows). Ich habe keine Ahnung, wie verschieden die sind und warum es hier nur um i5/OS geht.

    Markus

  5. Re: Irgendwie erschließt sich mir der Sinn nicht...

    Autor: Hermann L. 28.04.07 - 13:35

    > Unsinn. Im professionellen Datenbank Bereich
    > kommen 80% der Performance von einem guten
    > Queryplanner, und der ist bei MySQL derzeit noch
    > sehr dürftig. Klar, solche Sachen wie "select x
    > from y where z" performieren super mit MyISAM,
    > aber Queries dieser Art sind dort eher selten. Im
    > Webbereich stimmt dein Einwand natürlich, die
    > Abfragen die üblicherweise dort anzutreffen sind,
    > sind eher trivial.

    Vermutlich arbeitest Du mit veralteten Versionen. Wir setzen MySQL im Datawarehouse Bereich ein, und haben bei komplexeren Joins genau gegenteilige Erfahrung gesammelt: PostgreSQL konnte MySQL das Wasser nicht reichen und fiel damit aus dem Rennen.

    Und ich denke, dass dies nicht ein Einzelfall ist. SAP beispielsweise, hat als weitere Datenbank, die mit R/3 zusammenarbeitet MySQL, nicht aber PostgreSQL gewählt.

    Was natürlich nicht heissen soll, das PostgreSQL besser oder schlechter ist. Beide sind OpenSource, und der Anwender hat das Glück sich frei entscheiden zu können.

  6. MySQL ist halt gerade "in".

    Autor: Termigrator 13.09.07 - 12:39

    Markus42 schrieb:
    -------------------------------------------------------
    > AlexNofftz schrieb:
    > --------------------------------------------------
    > -----
    >> Irgendwie erschließt sich mir der Sinn dieser
    >> Maßnahme nicht. DB2 ist doch schon ein voll
    >> ausgereiftes DBMS, das sehr viel mehr als MySQL
    >> unterstützt.
    >
    > MySQL ist halt gerade "in".

    Und so kann man alte Datenbestände aus DB/2 mit neuen Mysql-Applikationen mischen und ggf. migrieren.


  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Hong Kong Economic and Trade Office, Berlin
  2. Universität der Bundeswehr München, Neubiberg
  3. TÜV SÜD Gruppe, München
  4. Technische Universität München, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 116,13€
  2. 229,99€
  3. 44,53€ (Exklusiv!) @ ubi.com
  4. 25,00€ (Bestpreis!)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Smarte Wecker im Test: Unter den Blinden ist der Einäugige König
Smarte Wecker im Test
Unter den Blinden ist der Einäugige König

Einen guten smarten Wecker zu bauen, ist offenbar gar nicht so einfach. Bei Amazons Echo Show 5 und Lenovos Smart Clock fehlen uns viele Basisfunktionen. Dafür ist einer der beiden ein besonders preisgünstiges und leistungsfähiges smartes Display.
Ein Test von Ingo Pakalski

  1. Nest Hub im Test Google vermasselt es 1A

Google Maps: Karten brauchen Menschen statt Maschinen
Google Maps
Karten brauchen Menschen statt Maschinen

Wenn Karten nicht mehr von Menschen, sondern allein von Maschinen erstellt werden, erfinden diese U-Bahn-Linien, Hochhäuser im Nationalpark und unmögliche Routen. Ein kurze Liste zu den Grenzen der Automatisierung.
Von Sebastian Grüner

  1. Kartendienst Google bringt AR-Navigation und Reiseinformationen in Maps
  2. Maps Duckduckgo mit Kartendienst von Apple
  3. Google Maps zeigt Bikesharing in Berlin, Hamburg, Wien und Zürich

Mobile Payment: Mit QR-Code-Kooperation zum europäischen Standard
Mobile Payment
Mit QR-Code-Kooperation zum europäischen Standard

Die Mobile Wallet Collaboration will ein einheitliches QR-Format als technische Grundlage für ein vereinfachtes Handling etablieren. Die Allianz aus sechs europäischen Bezahldiensten und Alipay aus China ist eine ernstzunehmende Konkurrenz für Google, Apple, Facebook, Amazon.
Von Sabine T. Ruh


    1. UMTS: 3G-Abschaltung kein Thema für die Bundesregierung
      UMTS
      3G-Abschaltung kein Thema für die Bundesregierung

      Nutzer, die kein LTE in ihren Verträgen festgeschrieben haben, sollten wechseln, da 3G zunehmend abgeschaltet werde. Das erklärte das Bundesverkehrsministerium und sieht keinen Grund zum Eingreifen.

    2. P3 Group: Wo die Mobilfunkqualität in Deutschland am niedrigsten ist
      P3 Group
      Wo die Mobilfunkqualität in Deutschland am niedrigsten ist

      Die Qualität des Mobilfunks in Deutschland ist in den einzelnen Bundesländern sehr unterschiedlich. Dort, wo Funklöcher gerade ein wichtiges Thema sind, ist die Versorgung gar nicht so schlecht.

    3. Mecklenburg-Vorpommern: Funkmastenprogramm verzögert sich
      Mecklenburg-Vorpommern
      Funkmastenprogramm verzögert sich

      Wegen fehlender Zustimmung der EU ist das Geld für ein Mobilfunkprogramm in Mecklenburg-Vorpommern noch nicht verfügbar. Dabei hat das Bundesland laut einer P3-Messung große Probleme.


    1. 18:00

    2. 18:00

    3. 17:41

    4. 16:34

    5. 15:44

    6. 14:42

    7. 14:10

    8. 12:59