Daniel: mySQL unprofessionell?

Tag zusammen,

seit kurzem habe ich mit recht großen Datenmengen zu tun (Tabellen bis 6 Millionen Zeilen). Zunächst stellte ich voller Schrecken fest, das mySQL kein CREATE VIEW kennt (?!?), der nächste Schock bestand aus der Fehlermeldung "mysqlimport: Error: The used command is not allowed with this MySQL version, when using table xyz" bei dem Versuch eines Datenimports per mysqlimport.

Ich nutze die aktuellste stable mySQL Version 3.23.55, und jetzt stellt sich mir die Frage: Kann man mit mySQL überhaupt professionell arbeiten?
Oder gibt es gangbare Alternativen für den Import großer Datenmengen und die "CREATE VIEW"-Anweisung?

Dank vorab,
Daniel

  1. Hi

    seit kurzem habe ich mit recht großen Datenmengen zu tun (Tabellen bis 6 Millionen Zeilen). Zunächst stellte ich voller Schrecken fest, das mySQL kein CREATE VIEW kennt (?!?), der nächste Schock bestand aus der Fehlermeldung "mysqlimport: Error: The used command is not allowed with this MySQL version, when using table xyz" bei dem Versuch eines Datenimports per mysqlimport.

    Ich nehme an, die Daten bestehen bereits in anderer Form? Dann dumpe sie ordentlich und inserte sie in mysql auf der mysql-Konsole mit source [filename]
    CREATE VIEW gibbet nu mal nicht.

    Ich nutze die aktuellste stable mySQL Version 3.23.55, und jetzt stellt sich mir die Frage: Kann man mit mySQL überhaupt professionell arbeiten?

    Sicher. Ich kenne viele Leute, die komplexe Anwendungen mit MySQL abgebildet bekommen haben. _Gerade_ bei großen Datenmengen.

    Fabian

    1. Ich nehme an, die Daten bestehen bereits in anderer Form? Dann dumpe sie ordentlich und inserte sie in mysql auf der mysql-Konsole mit source [filename]
      CREATE VIEW gibbet nu mal nicht.

      Genau da liegt das Problem, anstelle von CREATE VIEW nutze ich

      SELECT x FROM y WHERE z
      GROUP BY a
      ORDER BY b
      INTO OUTFILE 'C:\temp\out.txt';

      um die Daten zu Auswertungszwecken zu kumulieren.
      Funktioniert auch wunderbar, bloß: Wie bekomm ich die Daten der Datei out.txt dann wieder in die Datenbank?

      1. Hallo!

        SELECT x FROM y WHERE z
        GROUP BY a
        ORDER BY b
        INTO OUTFILE 'C:\temp\out.txt';

        um die Daten zu Auswertungszwecken zu kumulieren.
        Funktioniert auch wunderbar, bloß: Wie bekomm ich die Daten der Datei out.txt dann wieder in die Datenbank?

        Ich weiß jetzt nicht genau was Du da vorhast. Im Allgemeinen hast Du mehrere Möglickeiten:

        mysqldump datenbank > datensicherung.sql

        Diese kann man zurück in MySQL einlesen mit:

        mysql datenbank < datensicherung.sql

        http://de.mysql.com/documentation/mysql/bychapter/manual.de_MySQL_Database_Administration.html#mysqldump

        Hat ales Vor- dn Nachteile, am besten guckst Du mal in die Doku:

        http://de.mysql.com/documentation/mysql/bychapter/

        Viele Grüße
        Andreas

        1. Danke!
          Ich glaub' besonders das INSERT INTO ... SELECT hilft mir wirklich weiter.

          Gruß Daniel

      2. Hi

        Genau da liegt das Problem, anstelle von CREATE VIEW nutze ich

        SELECT x FROM y WHERE z
        GROUP BY a
        ORDER BY b
        INTO OUTFILE 'C:\temp\out.txt';

        um die Daten zu Auswertungszwecken zu kumulieren.
        Funktioniert auch wunderbar, bloß: Wie bekomm ich die Daten der Datei out.txt dann wieder in die Datenbank?

        So nicht. Deine Datenbank wird sicher eine andere Technik zum Export der Datenbestände unterstützen, bei MySQL ist das MySQL-Dump, das man als Programm in /bin findet und das mysqldump heißt. Dieses Programm erstellt eben keine reinen Datenfiles, sondern Files, die aus SQL-Statements bestehen, also INSERT INTO y (x,z) VALUES 'a','b' etc.
        Diese Files kannst du am mysql-Prompt mit "source filename" importieren.

        Sie halt zu, dass du SQL-Output bekommst, keinen reinen Datenstrom. Diesen kannst du ohne Probleme importieren.

        So kann man übrigens sehr bequem Backups machen, wenn man einen Cron-Job immer mal wieder so einen Dump machen lässt.

        Fabian

      3. Hi Daniel,

        um die Daten zu Auswertungszwecken zu kumulieren.

        was verstehst Du unter "kumulieren"?

        Funktioniert auch wunderbar, bloß: Wie bekomm ich die Daten der Datei out.txt dann wieder in die Datenbank?

        Wenn Du ein bestimmtes Import-Format brauchst, dann hast Du beim Exportieren zwei Möglichkeiten:

        • Entweder Du exportierst irgendwas und läßt anschließend einen Konverter drüber laufen
        • oder Du konvertierst in einem Format, das Du direkt wieder importieren kannst.

        Für beides gibt es viele Möglichkeiten - eine Datei voller SQL-Statements, eine CSV-artige Datei für den "mysqlimport" usw.

        Viele Grüße
              Michael

        --
        T'Pol: I apologize if I acted inappropriately.
        V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
  2. Hallo!

    Ich nutze die aktuellste stable mySQL Version 3.23.55, und jetzt stellt sich mir die Frage: Kann man mit mySQL überhaupt professionell arbeiten?
    Oder gibt es gangbare Alternativen für den Import großer Datenmengen und die "CREATE VIEW"-Anweisung?

    In MYsql gibt es keine Views, auch noch nicht in 4.0. Vielleicht in 4.1, siehe: http://de.mysql.com/documentation/mysql/bychapter/manual.de_Deutsch.html#ANSI_diff_Views

    In der aktuellen CT gibt es einen Artikel freie Datenbanken, mysql, postgres, SAP DB, Firebird: http://www.heise.de/ct/03/05/142/.

    MySQL ist für soche DInge nicht geeignet und hinkt dort sehr hinterher. Postgres kann das:
    http://www.postgresql.org/docs/view.php?version=7.3&idoc=0&file=rules-views.html
    http://www.selflinux.de/html/PostgreSQL04.html#d71e4275

    Viele Grüße
    Andreas

    1. Danke!

      Das fand ich sehr informativ, bloß war es eigentlich nicht ganz die Antwort die ich hören wollte, denn als mySQL-Freund würd ich doch lieber eine Alternative zur Vorgehensweise als etwas über alternative DB's erfahren ;-) Trotzdem, Danke!

  3. das schlimme imho ist ja das fehlen von subselects :(

    aber für eine gratis-db ist mysql top ;)

    1. Hi!

      das schlimme imho ist ja das fehlen von subselects :(

      Dann interessiert Dich sicher: http://www.mysql.com/press/release_2003_05.html
      http://www.mysql.com/doc/en/Nutshell_4.1_development_release.html
      Aber das dauert wohl noch ein wenig, da nichtmal 4.0 inzwischen als stable rausgegeben wurde. Aber als Alpha-Version kann man es durchaus schon testen!

      aber für eine gratis-db ist mysql top ;)

      Jepp, für einfache Anwendungen sicher, aber nicht die einzige, es gibt einige gute freie Datenbanken, und die können sogar mehr SQL(postgres z.B.)!

      Grüße
      Andreas

  4. Sup!

    Ich habe ja immer schon gesagt, das PostGreSQL die ueberlegene Datenbank ist.
    Wenn Du natuerlich lieber hoeren willst, dass mySQL besser ist, obwohl es nicht skaliert: mySQL ist besser!

    Ich schlage vor, die vorzuziehende Datenbank in den Self-Code aufzunehmen...

    db:p -> PostGreSQL
    db:o -> Oracle
    db:i -> InGres
    db:F -> Firebird
    db:$ -> SAPdb
    db:2 -> IBM db2
    db:x -> Andere, minderwertige Datenbank wie z.B. die peinliche PHP-Standarddatenbank mySQL oder die Atom-Sprengkopf-Anzahlen vergessende und per Wurm angreifbare Schergen-Datenbank MSSQL
    db:u -> Andere, sympathische Underdog-Datenbank

    Gruesse,

    Bio

    --
    Ich bin ein Mobber - mein Posting tut mir leid! EHRLICH!!!
    sh:( fo:) ch:] rl:} br:> n4:& ie:{ mo:) va:) de:] zu:) fl:( ss:) ls:]
    1. Hallo Bio,

      MS SQL-Server fehlt. Den hätte ich eigentlich hier

      db:$ -> SAPdb

      db:$ -> MS SQL-Server
      erwartet. ;-)

      Grüße
      Andreas

      1. Sup!

        MS SQL-Server fehlt. Den hätte ich eigentlich hier

        db:$ -> SAPdb
        db:$ -> MS SQL-Server
        erwartet. ;-)

        Voll nicht. Steht doch unter db:x schon drin.

        Gruesse,

        Bio

        --
        Ich bin ein Mobber - mein Posting tut mir leid! EHRLICH!!!
        sh:( fo:) ch:] rl:} br:> n4:& ie:{ mo:) va:) de:] zu:) fl:( ss:) ls:]
        1. Hallo Bio,

          Voll nicht. Steht doch unter db:x schon drin.

          Nur als "Andere", obwohl doch db:$ so schön zu M$ passen würde.

          Grüße
          Andreas

          1. Sup!

            Naja... da hast Du natürlich recht, aber ich wollte MSSQL so wenig Bedeutung wie möglich beimessen. Wir könnten natürlich db:$ für Micro$oft nehmen und db:S für SAP. Im Endeffekt nehmen sich aber SAP und Microsoft vielleicht nicht sehr viel - abgesehen davon, daß SAPs Software wirklich funktionieren soll.

            Gruesse,

            Bio

            --
            Ich bin ein Mobber - mein Posting tut mir leid! EHRLICH!!!
            sh:( fo:) ch:] rl:} br:> n4:& ie:{ mo:) va:) de:] zu:) fl:( ss:) ls:]
        2. Port!

          MS SQL-Server fehlt. Den hätte ich eigentlich hier

          db:$ -> SAPdb
          db:$ -> MS SQL-Server
          erwartet. ;-)

          Voll nicht. Steht doch unter db:x schon drin.

          Was natürlich vollkommen falsch ist, denn wenn schon dann hat db:x eine XML-DB zu bedeuten.

          Grüße
          Thomas

    2. Sup!

      Moin

      Was ist mit Cybase?

      Gruesse,

      Bio

      Gruß Christoph

      --
      Ich bin ein spezialisz!
      (Zitat von VENGA JO)
  5. Hi Daniel,

    seit kurzem habe ich mit recht großen Datenmengen zu tun (Tabellen bis 6 Millionen Zeilen).

    Sun Microsystems Inc.   SunOS 5.8       Generic February 2000

    /usr/local/shark (shark/clcfx03c) mysql -uXXXXXXXX -pXXXXXXXX

    Welcome to the MySQL monitor.  Commands end with ; or \g.

    Your MySQL connection id is 398364 to server version: 3.23.47-log

    Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

    mysql> use tkdsearch1;

    Database changed

    mysql> select count(*) from t_name;

    +----------+

    | count(*) |

    +----------+

    | 19344331 |

    +----------+

    1 row in set (0.01 sec)

    mysql> exit

    Bye

    Ich nutze die aktuellste stable mySQL Version 3.23.55, und jetzt stellt sich mir die Frage: Kann man mit mySQL überhaupt professionell arbeiten?

    Klar kann man.

    Es kommt immer darauf an, was Deine Aufgabenstellung verlangt.
    Für gut geindexte readonly-Zugriffe ist mySQL ausgezeichnet, während ich ein accounting-relevantes Transaktionssystem weitaus weniger gerne darauf implementieren würde ... was allerdings hauptsächlich an den passenden Tabellentreibern liegt. "mySQL" existiert in dieser Hinsicht gar nicht wirklich - InnoDB kann in den meisten Aspekten seiner Mächtigkeit mit Oracle durchaus mithalten.

    Viele Grüße
          Michael

    --
    T'Pol: I apologize if I acted inappropriately.
    V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
    1. Hallo Michael!

      Für gut geindexte readonly-Zugriffe ist mySQL ausgezeichnet, während ich ein accounting-relevantes Transaktionssystem weitaus weniger gerne darauf implementieren würde ... was allerdings hauptsächlich an den passenden Tabellentreibern liegt. "mySQL" existiert in dieser Hinsicht gar nicht wirklich - InnoDB kann in den meisten Aspekten seiner Mächtigkeit mit Oracle durchaus mithalten.

      Du würdest es mit mysql nicht gerne umsetzen obwohl Du einen Satz später sagst die Tabellentreiber von InnoDB seien mit denen von Oracle auf einer Höhe? Heißt das Du würdest auch auf Oracle ungerne ein "accounting-relevantes Transaktionssystem" (was auch immer das im Detail ist ;-)) umsetzen? Welches DBMS würdest Du denn für Transaktionen präferieren? Wie gut kennst Du dies bezüglich Postgres?

      Grüße
      Andreas

      1. Hi Andreas,

        Du würdest es mit mysql nicht gerne umsetzen obwohl Du einen Satz später sagst die Tabellentreiber von InnoDB seien mit denen von Oracle auf einer Höhe?

        Ich habe InnoDB noch nicht selbst eingesetzt - aber das mySQL-Handbuch über alle Tabellentypen sequentiell gelesen und an Begriffen wie "Tablespace" und "Rollbacksegment" und noch ein paar andere viele liebgewordene Oracle-Konzepte wiederentdeckt. Ich weiß aber nicht, was ich alles tun müßte, um InnoDB-Tabellen verwenden zu dürfen (ich habe noch kein mySQL selbst installiert - für Maschineninstallationen gibt es hier einen Kollegen, der auf Betriebskonzepte spezialisiert ist, ich selbst gehe erst auf die Maschine, wenn sie "läuft").

        Heißt das Du würdest auch auf Oracle ungerne ein "accounting-relevantes Transaktionssystem" (was auch immer das im Detail ist ;-))

        Eines, was Du vertrauensvoll in Deiner Bank eingesetzt sehen wollen würdest, die Dein Gehaltkonto und Deine Überweisungen damit verwaltet.

        umsetzen? Welches DBMS würdest Du denn für Transaktionen präferieren?

        Da reicht mir "Transaktionen" als Kriterium nicht aus.

        Meine Oracle-Erfahrungen basieren auf anderen Randbedingungen:

        • erstens  gab es damals noch kein mySQL, kein Perl, kein DBI, kein PHP, kein HTTP und kein HTML;
        • zweitens gab es von Oracle alles, was wir brauchten, auf der gewünschten Plattform - und das umfaßte insbesondere APIs nach C und Views und Constraints und Trigger und Stored Procedures in PL/SQL und einen mitgelieferten Formulargenerator und einen Reportgenerator.

        Oracle 6 konnte einfach all das und noch etwa 500% mehr ... ich habe noch heute einen Meter Oracle-Handbücher im Schrank stehen, obwohl ich seit Jahren gar kein Oracle mehr verwende - einige der Bücher sind einfach produktübergreifend gut geschrieben.

        Wie gut kennst Du dies bezüglich Postgres?

        Gar nicht.

        Viele Grüße
              Michael

        --
        T'Pol: I apologize if I acted inappropriately.
        V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
        (sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)