MySQL: Zeichensatz unter Windows, DB-Verzeichnisse

[idefix2]

Hallo,

ich habe mir eben einen MySQL Server installiert, weil ich daran denke, meine Applikationen von MS-Access auf MySQL umstellen. Aber noch bevor ich zu den allerersten Schritten komme, tun sich schon die ersten zwei Hindernisse auf:

Ich habe MySql mit den Standardvorgaben installiert - da heisst der Zeichensatz Latin-1 - bei dem werden aber alle Umlaute aus den Access-Tabellen zu irgendwas unbrauchbaren konvertiert. Welcher MySQL Zeichensatz entspricht dem normalen in Windows verwendeten Zeichensatz?

und die zweite Frage: Ich würde gerne verschiedene Datenbanken an verschiedenen Orten des Servers, teilweise auch auf unterschiedlichen Platten, anlegen, und zwar jeweils in ein Unterverzeichnis der zugehörigen Applikation. Ist das mit MySQL überhaupt möglich?

[Bernhard Geyer]

Zitat:

Zitat von idefix2

Ich habe MySql mit den Standardvorgaben installiert - da heisst der Zeichensatz Latin-1 - bei dem werden aber alle Umlaute aus den Access-Tabellen zu irgendwas unbrauchbaren konvertiert. Welcher MySQL Zeichensatz entspricht dem normalen in Windows verwendeten Zeichensatz?

Nimm UTF8/UCS2 bei MySQL und alles wird gut. In 2010 mit Codepages/Charsets sich herumärgern ist für ein neues Projekt ein absolutes NO-GO.

[idefix2]

Leider wurde nicht alles gut:

Ich habe den default charset von MySQL auf UTF8 umgestellt, den MySQL-Dienst neu gestartet (steht jetzt auch in DB.OPT so drinnen) und eine neue Datenbank und darin eine neue Tabelle erstellt.

Ich habe aus meiner alten Access-Datenbank ein Tab-delimited file erzeugt, in diesem File zeigt mir z.B. der Windows Editor die Umlaute richtig an, habe dann noch alle "\" in "\\" konvertiert und dann:

LOAD DATA LOCAL INFILE 'd:/test.txt' INTO TABLE musik;

auf der MYSQL Kommandozeile eingegeben, um die Tabelle zu importieren.

Ergebnis: Die Tabelle wird zwar importiert, aber alle Felder, die Umlaute enthalten, brechen jetzt unmittelbar vor dem ersten Umlaut ab, enthalten also nur die Zeichen bis zum ersten Umlaut - mit latin1 wurden zwar die Umlaute falsch konvertiert, aber zumindest die Datenfelder komplett eingelesen.

[mkinzler]

Ich würde die Daten direkt von der Access-Tabelle in die MySQL-Tabelle kopieren.

[mjustin]

Zitat:

Zitat von idefix2

Leider wurde nicht alles gut:

Ich habe den default charset von MySQL auf UTF8 umgestellt, den MySQL-Dienst neu gestartet (steht jetzt auch in DB.OPT so drinnen) und eine neue Datenbank und darin eine neue Tabelle erstellt.

Ich habe aus meiner alten Access-Datenbank ein Tab-delimited file erzeugt, in diesem File zeigt mir z.B. der Windows Editor die Umlaute richtig an, habe dann noch alle "\" in "\\" konvertiert und dann:

LOAD DATA LOCAL INFILE 'd:/test.txt' INTO TABLE musik;

auf der MYSQL Kommandozeile eingegeben, um die Tabelle zu importieren.

Ergebnis: Die Tabelle wird zwar importiert, aber alle Felder, die Umlaute enthalten, brechen jetzt unmittelbar vor dem ersten Umlaut ab, enthalten also nur die Zeichen bis zum ersten Umlaut - mit latin1 wurden zwar die Umlaute falsch konvertiert, aber zumindest die Datenfelder komplett eingelesen.

Eventuell ist diese Seite hilfreich:

"LOAD DATA INFILE and UTF-8"
http://bugs.mysql.com/bug.php?id=10195

Dort werden diverse Parameter und Umgebungsvariablen beschrieben.

Was ich (ohne die genannte Seite gelesen zu haben) intuitiv versuchen würde wäre, die Textdatei in UTF-8 zu kodieren, z.B. in der Delphi IDE.

[idefix2]

Danke, die Seite war hilfreich: Ich werde von MySQL die Finger lassen.

Bei einem DBMS, das auf einem PC laufen soll, und das im Jahr 2010 offenbar noch nicht die Möglichkeit bietet, normale PC-Umlaute auf einfache Art zu handhaben, fühle ich mich nicht gut aufgehoben :-D

[Bernhard Geyer]

Zitat:

Zitat von idefix2

Danke, die Seite war hilfreich: Ich werde von MySQL die Finger lassen.

Bei einem DBMS, das auf einem PC laufen soll, und das im Jahr 2010 offenbar noch nicht die Möglichkeit bietet, normale PC-Umlaute auf einfache Art zu handhaben, fühle ich mich nicht gut aufgehoben :-D

Also wir verwenden MySQL mit Unicode (Deutsche Umlaute, Chinesisch, Ararbisch) seit ca. 2003 und haben damit eigentlich sehr wenig Probleme (im Gegensatz zu diversen Oracle-Installationen). Im Notfall implementiert man sich eine eigene "Datapump" in 1-2 Tagen.

[mkinzler]

Aus meiner Sicht würden eher andere Dinge gegen MySQL sprechen

[Bernhard Geyer]

Zitat:

Zitat von mkinzler

Aus meiner Sicht würden eher andere Dinge gegen MySQL sprechen

Wenn man die Punkte betrachtet:

Zitat:

Zitat von idefix2

und die zweite Frage: Ich würde gerne verschiedene Datenbanken an verschiedenen Orten des Servers, teilweise auch auf unterschiedlichen Platten, anlegen, und zwar jeweils in ein Unterverzeichnis der zugehörigen Applikation. Ist das mit MySQL überhaupt möglich?

Würde das eher nach einer embedded-DB-Lösung sprechen. Hier wäre MySQL auch im Rennen, wenn da nicht die GPL-Falle zuschlägt:

Frage:
Sind die Anwendungen OpenSource-Anwendungen?
Falls nein: Können 30 k€ pro Jahr Lizenzkosten verkraftet werden (bzw. 1 MySQL-Serverlizenz pro Server?)

[mkinzler]

Muss nicht unbedingt für embedded sprechen. Jede Anwendung könnte ja theoretisch von mehreren Benutzern verwendet werden.
Wenn es sich um keine OS Lösung handelt und die Anwendungen u.U. weitergegeben werden sollen, würde ich nicht aud MySQL setzen.
Zudem hier weitere Änderungen seitens Oracle zu befürchten sind ( droppen der Falcon-Storage-Enhine vom Interbase/Firebird "Erfinder" Jim Starkey ist möglichweise nur der 1. Schritt)

[fatalerror]

Zitat:

Zitat von Bernhard Geyer

Falls nein: Können 30 k€ pro Jahr Lizenzkosten verkraftet werden (bzw. 1 MySQL-Serverlizenz pro Server?)

Bin jetzt grad richtig erschrocken, wie kommst du auf diese Preise? Das waren doch mal 500 € pro Server oder liege ich da total falsch?

[idefix2]

Zitat:

Im Notfall implementiert man sich eine eigene "Datapump" in 1-2 Tagen.

Natürlich kann man im Notfall alles mögliche machen. Bloss fühle ich mich eigentlich verarscht, wenn ein Programm, das auf einem PC laufen soll, den normalen PC Zeichensatz nicht beherrscht. Und dass MySQL jetzt von Oracle übernommen wurde, spricht natürlich auch nicht dafür, in Zukunft auf dieses Pferd zu setzen.

Zitat:

Aus meiner Sicht würden eher andere Dinge gegen MySQL sprechen

Stimmt. Wenn es das einzige wäre, würde ich wahrscheinlich die Krot schlucken und erst einmal schauen, wie ich die Umlaute in die Datenbank hineinbekomme. Aber so wie die Dinge liegen, werde ich die MySQL Variante nicht mehr weiter verfolgen. Schau mir gerade SQLite an, das könnte für meine Bedürfnisse fürs erste reichen. Die sehr eingeschränkte Mehrplatzfähigkeit bereitet mir allerdings etwas Bauchweh. Für die Sachen, die ich jetzt gerade mache, kein Problem, aber wenn ich irgendwann wieder ein echtes Multiuser-System brauche, muss ich mich erst wieder nach etwas anderen umschauen.

[omata]

Warum schaust du dir dann nichtmal Firebird an?

[mkinzler]

Zitat:

Zitat von omata

Warum schaust du dir dann nichtmal Firebird an?

Das wäre auch mein Tip

[Bernhard Geyer]

Zitat:

Zitat von fatalerror

Zitat:

Zitat von Bernhard Geyer

Falls nein: Können 30 k€ pro Jahr Lizenzkosten verkraftet werden (bzw. 1 MySQL-Serverlizenz pro Server?)

Bin jetzt grad richtig erschrocken, wie kommst du auf diese Preise? Das waren doch mal 500 € pro Server oder liege ich da total falsch?

Das sind die Kosten einer Firmenlizenz bei unbeschränkter Verteilung (AFAIK aber nur für MyISAM, InnoDB war irgendwie das doppelte).
Wenn die Anzahl der Installationen gering ist, ist es natürlich günstiger pro Server zu Lizensieren.

Zitat:

Zitat von idefix2

Natürlich kann man im Notfall alles mögliche machen. Bloss fühle ich mich eigentlich verarscht, wenn ein Programm, das auf einem PC laufen soll, den normalen PC Zeichensatz nicht beherrscht.

Der "normale" Zeichensatz unter Windows ist Unicode. Der Zeichnesatz-Support sit nur nötig für "legacy" Anwendungen die kein Unicode beherrschen.

Zitat:

Zitat von idefix2

... Die sehr eingeschränkte Mehrplatzfähigkeit bereitet mir allerdings etwas Bauchweh. Für die Sachen, die ich jetzt gerade mache, kein Problem, aber wenn ich irgendwann wieder ein echtes Multiuser-System brauche, muss ich mich erst wieder nach etwas anderen umschauen.

Am besten das System DB-Neutral (z.B. mit Brige-Pattern) aufbauen so das du später einfach weitere Unterstützte DB-System hinzufügen kannst und der Kunde wählt dann sein System aus das er eh im Hause hat.

[idefix2]

Zitat:

Der "normale" Zeichensatz unter Windows ist Unicode. Der Zeichnesatz-Support sit nur nötig für "legacy" Anwendungen die kein Unicode beherrschen.

Bis jetzt hat mich unter Windows noch kein Programm dazu gezwungen, mich mit unterschiedlichen Zeichensätzen herumzuschlagen, abgesehen von der Konversion von alten MS-Dos Files und abgesehen von Mailprogrammen, die diesbezüglich oft sehr mühsam sind - den Indy Komponenten das Versenden von Mails mit Umlauten beizubringen, die auch richtig als Umlaute beim Mail-Empfänger ankommen, war eine Herausforderung.

Den Zeichensatz, mit dem die üblichen Windows Programme arbeiten (Standard-Installation vorausgesetzt), würde ich als einen normalen Windows Zeichensatz bezeichnen. Ein DBMS, das auf einem Windows Rechner läuft, muss mit diesem Zeichensatz zurechtkommen. Erstelle z.B. mit Notepad ein einfaches tab-delimited File mit Umlauten und lass mich wissen, wie Du das ohne Zusatzprogrammierung (ich meine echte Zusatzprogrammierung, die Anpassung von irgend welchen Parametern im MySQL wäre ja durchaus in Ordnung) mit MySQL-eigenen Mitteln in eine MySQL Tabelle importierst.

[idefix2]

Zitat:

Warum schaust du dir dann nichtmal Firebird an?

bin schon dabei :)

[Bernhard Geyer]

Zitat:

Zitat von idefix2

Bis jetzt hat mich unter Windows noch kein Programm dazu gezwungen, mich mit unterschiedlichen Zeichensätzen herumzuschlagen,

Auch wenns Off-Topic wird: Diverse Betas von OpenOffice waren unfähig Dateien mit Sonderzeichen zu öffnen.
Und wenn du Lazarus/FreePascal-Programme verwendet könnte das auch passieren - siehe diverse Threads zu UTF8-Codierung in der FCL/...

Zitat:

Zitat von idefix2

Erstelle z.B. mit Notepad ein einfaches tab-delimited File mit Umlauten und lass mich wissen, wie Du das ohne Zusatzprogrammierung (ich meine echte Zusatzprogrammierung, die Anpassung von irgend welchen Parametern im MySQL wäre ja durchaus in Ordnung) mit MySQL-eigenen Mitteln in eine MySQL Tabelle importierst.

Brauch ich nicht machen. Unser Apps können sowas. Da brauch ich mich (wie auch bei anderen DB's) mich nicht mit dem Textdateiimport herumschlagen.

[idefix2]

Natürlich brauchst Du das nicht (egal ob Deine Apps das können oder nicht).
Der Punkt ist, dass MySQL es nicht kann.

Kann ein DBMS Trigger? Braucht es nicht, meine Apps handeln das ohnehin.
Kann ein DBMS Stored Procedures? Braucht es nicht, die Prozeduren sind ohnehin in meinen Apps programmiert.
Kann ein DBMS ....? Braucht es nicht ....

Auf der Basis gibt es eigentlich keine Kriterien für die Beurteilung von irgendwas.

[mkinzler]

Zitat:

Kann ein DBMS Trigger? Braucht es nicht, meine Apps handeln das ohnehin.

Trigger könnten u.U. aber doch Vorteile bieten

Zitat:

Kann ein DBMS Stored Procedures? Braucht es nicht, die Prozeduren sind ohnehin in meinen Apps programmiert.

Das ist nicht das Selbe.

[idefix2]

@mkinzler
Ich glaube, Du hast mein Posting völlig mißverstanden.

Bernhard Geyer hat geschrieben:

Zitat:

Brauch ich nicht machen. Unser Apps können sowas.

und ich wollte ihn mit diesen Beispielen darauf hinweisen, dass es für die Beurteilung einer Datenbanksoftware völlig irrelevant ist, ob irgendwelche Apps die angeprochenen Datenbankfunktionen substituieren können.

[idefix2]

Zitat:

Am besten das System DB-Neutral (z.B. mit Brige-Pattern) aufbauen

Im Prinzip hast Du natürlich Recht, das wäre das Beste. Bloss unterscheiden sich die verschiedenen SQL Dialekte untereinander doch so massiv, hinsichtlich der Datentypen ebenso wie hinsichtlich der Funktionalität, dass eine Beschränkung auf den "kleinsten gemeinsamen Nenner" eigentlich nicht wirklich machbar oder zumindest extrem aufwändig und einschränkend wäre?

Ausserdem müsste man auf die zusätzliche Funktionalität verzichten, die jedes DBMS bietet - man würde also um der Kompatibilität willen von allen Welten mehr oder weniger nur das Schlechteste nehmen?

[Bernhard Geyer]

Ohne Aufwand ist es nicht (aber es gibt ja mittlerweile fertige Frameworks).

Und mit solchen Ansatz bist du nicht Schuld beim Kunden ein DBMS eingeführt zu haben. Du brauchst dich auch nicht um Backupstrategien zu kümmern (die gibt es ja schon bei den Firmen). Mann kann dich auch nicht für allen möglichne anderen Support einspannen ("Sie haben doch hier das DBMS xyz installiert. Wir haben da jetzt probleme ...") auch wenn es mit dem System gar nix zu tun hat.

[idefix2]

Zitat:

es gibt ja mittlerweile fertige Frameworks

Kanst Du mir einen Tip geben, welche Tools es da gibt und wo die zu finden sind? Ich würde mir so etwas zumindest gerne anschauen, bevor ich mich endgültig in irgend eine Richtung bewege.

Mein Befürchtung ist, dass damit die Programme viel aufwändiger zu erstellen werden und gleichzeitig, je nachdem wie die Dinge arbeiten, auch die Performance leidet. Aber vielleicht (hoffentlich) ist das ein Irrtum.