MySQL Ausgabe mit vielen Spalten formatieren

Es passiert mir schon einmal öfters, dass ich in der Konsole eine SQL-Query absetze, die mehrere Spalten beinhaltet. Dabei sorgt die hohe Menge an Spalten in der Ausgabe für einen Zeilenumbruch der Standardformatierung von MySQL und die generierten Tabellenansichten sind nicht mehr übersichtlich. Solange das Fenster sich breit genug ziehen lässt ist dies grunsätzlich nicht problematisch. Jedoch bringt diese Formatierung einen schnell an die Grenzen, weil schon allein die Dateninhalte einer einzigen Spalte mal länger als eine Zeile sein können. Und spätestens dann wird es richtig ekelig zu erkennen welche Eintrag in welcher Spalte einer Zeile wo zu verorten ist.

Die Lösung ist einfacher als man glaubt, denn schon mit den Standardboardmitteln der MySQL Konsole lässt sich die Ausgabe der Spalten formatieren. Ein Resultset welches die für die aktuelle Ansicht einfach zu breit in der Ausgabe ist sieht exemplarisch wie folgt aus:

mysql> select now() as date_1, now() as date_2, now() as date_3, now() as date_4, now() as date_5, now() as date_6, now() as date_7, now() as date_8, now() as date_9 union all select now() as date_1, now() as date_2, now() as date_3, now() as date_4, now() as date_5, now() as date_6, now() as date_7, now() as date_8, now() as date_9;

+---------------------+---------------------+---------------------+---------------------+---------------------+---------------------+---------------------+---------------------+---------------------+
| date_1              | date_2              | date_3              | date_4              | date_5              | date_6              | date_7              | date_8              | date_9              |
+---------------------+---------------------+---------------------+---------------------+---------------------+---------------------+---------------------+---------------------+---------------------+
| 2018-09-15 08:53:45 | 2018-09-15 08:53:45 | 2018-09-15 08:53:45 | 2018-09-15 08:53:45 | 2018-09-15 08:53:45 | 2018-09-15 08:53:45 | 2018-09-15 08:53:45 | 2018-09-15 08:53:45 | 2018-09-15 08:53:45 |
| 2018-09-15 08:53:45 | 2018-09-15 08:53:45 | 2018-09-15 08:53:45 | 2018-09-15 08:53:45 | 2018-09-15 08:53:45 | 2018-09-15 08:53:45 | 2018-09-15 08:53:45 | 2018-09-15 08:53:45 | 2018-09-15 08:53:45 |
+---------------------+---------------------+---------------------+---------------------+---------------------+---------------------+---------------------+---------------------+---------------------+
2 rows in set (0.00 sec)

Das Ergebnis sieht ziemlich kryptisch aus – oder?

Um diese Ausgabe übersichtlicher darzustellen gibt es die Option \G. Diese Option wird der vorhandenen Query einfach angehangen. Sodann wird die Ausgabe der Query jede Zeile des Resultsets in einem separaten Block darstellen. Jede Spalte Pro Block wird in einer eigenen Zeile inklusive einem Spaltenlabel ausgegeben.

Für das obige Beispiel sieht das Ergebnis in der Konsole dann wie folgt aus:

mysql> select now() as date_1, now() as date_2, now() as date_3, now() as date_4, now() as date_5, now() as date_6, now() as date_7, now() as date_8, now() as date_9 union all select now() as date_1, now() as date_2, now() as date_3, now() as date_4, now() as date_5, now() as date_6, now() as date_7, now() as date_8, now() as date_9 \G;

*************************** 1. row ***************************
date_1: 2018-09-15 08:54:15
date_2: 2018-09-15 08:54:15
date_3: 2018-09-15 08:54:15
date_4: 2018-09-15 08:54:15
date_5: 2018-09-15 08:54:15
date_6: 2018-09-15 08:54:15
date_7: 2018-09-15 08:54:15
date_8: 2018-09-15 08:54:15
date_9: 2018-09-15 08:54:15
*************************** 2. row ***************************
date_1: 2018-09-15 08:54:15
date_2: 2018-09-15 08:54:15
date_3: 2018-09-15 08:54:15
date_4: 2018-09-15 08:54:15
date_5: 2018-09-15 08:54:15
date_6: 2018-09-15 08:54:15
date_7: 2018-09-15 08:54:15
date_8: 2018-09-15 08:54:15
date_9: 2018-09-15 08:54:15
2 rows in set (0.00 sec)

Damit wird es möglich ziemlich einfach visuell zu erfassen welche Datenausgabe zu welcher Spalte gehört.

Umlaute in HeidiSQL werden falsch angzeigt

Bei der Arbeit mit HeidiSQL habe ich das Problem, dass Umlaute je nach Datenbank falsch angezeigt werden und nicht lesbar sind. Diese werden von HeidiSQL standardmäßig in UTF-8 kodiert angenommen. Allerdings ist die Default-Charset meiner Datenbank mit einer anderen Kodierung vorgesehen, nämlich in latin-1.

In den Einstellungen von HeidiSQL kann man jedoch keine passende Option dazu finden diese Collation zu ändern. Und das weder in den globalen, noch in den verbindungspezifischen Einstellungen.

Eine Ausgabe in den Ergebnisdaten mit Umlauten sieht dann möglicherweise wie folgt aus:

select lastname from users where id = 1;

> Schröder

Lösung

Nachdem folgende SQL Abfrage abgesetzt wurde werden die Umlaute aller künftigen SQL-Abtragen innerhalb der aktuellen Verbindung  korrekt dargestellt.

SET NAMES 'latin1';

Nachdem diese Query abgesetzt wurde, werden die Umlaute korrekt dargestellt. So sieht die ursprünglich falsche Antwort nun korrekt aus:

select lastname from users where id = 1;
> Schröder

Weiterführende Literatur

Mysql Datenbank kopieren bzw. duplizieren

Möchte man in Mysql eine Datenbank kopieren bzw. duplizieren kann man das leider nicht in einem Schritt. Dies muss man in MySQL in drei Schritten vornehmen. Dazu muss zunächst die Quelldatenbank exportiert werden, dann wird die neue Datenbank erzeugt um abschließend die im ersten Schritt erzeugten Daten in die neue Datenbank zu importieren.

Vorgehensweise im Detail

1. Schritt: Exportieren der vorhandenen Daten aus der Quelldatebank auf der Konsole

[vader@deathstar ~]$ mysqldump SOURCE_DB > dump_db.sql

2. Schritt: Erzeugen der neuen Datenbank im SQL-Client

MariaDB [(none)]> create database TARGET_DB;

3. Schritt: Importieren der im ersten Schritt exportierten Daten in das neue Ziel – ebenfalls auf der Konsole

[vader@deathstar ~]$ mysql TARGET_DB < dump_db.sql

Mit dieser Schritt-für-Schritt-Anleitung kann man nun ganz einfach die Datenbank klonen.

Hat Dir das Tutorial geholfen? Hinterlass mir doch einen Kommentar

Weiterführende Literatur

Umstellung mysql auf mysqli

Mit PHP 5.5.0 wurden die alten mysql-Funktionen als deprecated markiert und seit PHP 7.0.0 gänzlich entfernt. Da inzwischen immer mehr Provider ihr Hostingangebote auf PHP 7 aktualisieren stehen diese Funktionen ab dieser Version dann gar nicht mehr zur Verfügung. Daher muss eine Umstellung dieser in den eigenen Projekten zwingend eingeplant werden. Dafür habe ich an dieser Stelle eine umfängliche Schritt-für-Schritt Anleitung zusammengestellt, welche bei sorgfältiger Abarbeitung einen innerhalb kurzer Zeit ziemlich sicher zum Ziel führt.

MySQL: Das umfassende Handbuch

Die Umstellung der mysql_*-Funktionen auf mysqli_*-Funktionen geht relativ reibungslos vonstatten, sofern man eine zentrale Verarbeitung der Datenbankabfragen implementiert hat. Ist dies nicht der Fall so wird sich der hier aufgeführte Aufwand um die Anzahl der zu behandelnden Stellen zuzüglich der notwendigen Tests in ungefähr multiplizieren.

Umsetzung

Für die Umstellung des eigenen Adapters muss man sich den nachfolgenden Punkten in jedem Einzelfall gesondert widmen und kann dazu wie folgt vorgehen:

  1. Im ersten Schritt ersetzt man alle mysql_ Funktionsaufrufe mit einem mysqli_. Das nachfolgende Suchpattern eignet sich hierfür sehr gut:
    /mysql_([a-z_]+)\(/
  2. In der Funktion mysqli_connect() werden ab dem vierten Parameter Port und Socket erwartet anstelle von link und clients. Sofern diese angegeben wurden müssen diese zunächst entfernt werden. Haben diese Angaben bisher darüber hinaus noch Relevanz gehabt so müssen jene an dieser Stelle gesondert behandelt werden.
  3. Die Funktionen mysqli_query()mysqli_error(), mysqli_escape_string() und mysqli_real_escape_string() benötigen nun zusätzlich die Angabe der Ressource. Dies kann für die beiden zuletzt genannten Funktionen an den Stellen problematisch werden, an denen eine Verbindung möglicherweise noch nicht hergestellt wurde oder die Ressource gar nicht erst verfügbar ist. Hier muss sichergestellt sein, dass diese vor dem ersten Aufruf aufgebaut wurde.
  4. In der Funktion mysqli_select_db() sind von nun an die beiden Parameter für Ressource und DB-Name vertauscht.
  5. Die vier Funktionen mysqli_fetch_assoc()mysqli_fetch_row()mysqli_fetch_object() und mysqli_fetch_array() liefern im Fall eines leeren Ergebnisses nun NULL wo ihre mysql-Pendants  hingegen bisher den Wert FALSE zurückgegeben haben.
  6. Andersherum jedoch liefert die Methode mysqli_stat() fortan FALSE anstelle von NULL sofern die Datenermittlung erfolglos stattgefunden hat.
  7. Prüfungen auf is_resource() sind nicht mehr möglich da der mysqli-Adapter keine PHP Ressourcen mehr darstellen sondern interne Klassenrepräsentationen.
    Konstrukte dieser Art:
    if( is_resource( $this->_link ) {     // ... }
    müssen überarbeitet und ersetzt werden gegen folgende Logik:
    if( $this->_link instanceof mysqli ) {     // ... }
  8. Die Funktion mysql_field_name() kann nicht ersetzt werden, da das entsprechende Pendant nicht existiert. Man muss es durch den nachfolgenden Schnipsel, Umsetzung in einer Klasse vorausgesetzt, ergänzen:
    private function field_name( $offset ) {
       $properties = mysqli_fetch_field_direct( $this->result, $offset );
       return is_object( $properties ) ? $properties->name : null; 
    }
    Anstelle von mysql_field_name( $resource, $offset ) erfolgt der Aufruf nun mit $this->field_name( $offset ).
  9. Der Abruf der Methoden mysqli_stat() und mysql_error() ohne Parameter ist nun nicht mehr zulässig und es muss die Ressource künftig mit angegeben werden.

Fazit

Ich stelle fest, dass eine Umstellung auf mysqli keine zeitaufwändige Angelegenheit ist und mit den wenigen notwendigen Tests innerhalb eines halben Arbeitstages nahezu mühelos erledigt werden kann.

Weiterführende Literatur