mySQL unprofessionell?

[Daniel]

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

[Fabian Transchel]

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

[Daniel]

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?

[Andreas Korthaus]

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:

• INSERT INTO tabelle SELECT bla FROM table WHERE.. http://de.mysql.com/documentation/mysql/bychapter/manual.de_Reference.html#INSERT_SELECT

• CREATE TABLE tabelle SELECT... http://de.mysql.com/documentation/mysql/bychapter/manual.de_Reference.html#CREATE_TABLE

• Wenn Du wie oben eien Datei exportiertst kannst Du eben die Datei mit LOAD DATA INFILE wieder einlesen: http://de.mysql.com/documentation/mysql/bychapter/manual.de_Reference.html#LOAD_DATA

• ich mache sowas immer über dei Kommandozeile mit

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

[Daniel]

• INSERT INTO tabelle SELECT bla FROM table WHERE.. http://de.mysql.com/documentation/mysql/bychapter/manual.de_Reference.html#INSERT_SELECT

• CREATE TABLE tabelle SELECT... http://de.mysql.com/documentation/mysql/bychapter/manual.de_Reference.html#CREATE_TABLE

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

Gruß Daniel

[Fabian Transchel]

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

[Michael Schröpl]

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

[Andreas Korthaus]

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

[Daniel]

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!

[Robert]

das schlimme imho ist ja das fehlen von subselects :(

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

[Andreas Korthaus]

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

[Bio]

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

[Andreas Schneider]

Hallo Bio,

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

db:$ -> SAPdb

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

Grüße
Andreas

[Bio]

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

[Andreas Schneider]

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

[Bio]

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

[Thomas J.S.]

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

[Christoph]

Sup!

Moin

Was ist mit Cybase?

Gruesse,

Bio

Gruß Christoph

[Michael Schröpl]

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

[Andreas Korthaus]

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

[Michael Schröpl]

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