MySQL Workbench

[Delbor]

Hi Valentin

Danke für die schnelle Antwort.

Zitat:

Falls man doch etwas manuell ändert, dann sollte man MySQL mal neu starten lassen. Allerdings entspricht in InnoDB nicht mehr jede Tabelle einer Datei, sodass ich von manuellen Änderungen generell abrate.

Das hab ich mal getan, bevor ich ein ForwardEngeering durchführte. Geändert hat sich nichts. Aber ich werd das mal wiederholen.

Zitat:

MySQL wird sich schon was dabei denken, wenn es meldet, dass die Tabelle bereits existiert. Was sagt denn SHOW TABLES dazu? Zeigt es die Tabelle auch an? Ich glaube eigentlich nicht, dass die Neuinstallation der MySQL Workbench hier einen Fehler behebt, zumindest sofern ich dein Prolem richtig verstanden habe. Eher hast du ein Problem mit deinem Server.

Da fällt mir doch glatt jene Signatur ein, die da heisst: Meistens sitzt das Problem zwischen den Ohren - denn natürlich hast du recht. Anstatt stundenlang nach irgendwelchen zuständigen Dateien und Verzeichnissen zu suchen, hätte ich von Anfang an SQL einsetzen sollen...

Ach ja: weisst du vielleicht gerade, was das bedeutet, wenn im Catalog tree von Workbench die Tabellenbezeichner am Schluss mit einem Punkt gekennzeichnet sind?

Gruss
Delbor

[Medium]

Grundsätzlich zu InnoDB unter MySQL: Uns ist nach diversen Rettungsversuchen von Datenbanken ähnliches wiederfahren - heisst die DB an sich war laut MySQl Administrator nicht mehr da, aber beim CREATE TABLE hieß es sie sei es doch. MySQL speichert das Verzeichnis von InnoDBs an anderer Stelle als die Daten, und der Verzeichniseintrag reicht aus, um einen Tabellennamen zu blockieren. Wo die jeweiligen Dateien genau sitzen hängt von deinen Einstellungen ab.
Wenn man es also in der Hand hat, ist der Hinweis niemals manuell an den Dateien selbst zu doktorn das einzig richtige. Im Zweifel würde ich hier MySQL komplett deinstallieren, und ganz neu aufsetzen. Setzt natürlich voraus, dass man sonst nichts wichtiges in der DB verliert - aber wenn man sich schon traut einfach mal Dateien zu löschen, kann das ja eigentlich nicht sein

[Delbor]

Hi Medium

Auch dir vielen Dank für deine Antwort. Ich denke schon, dass es erstmal daran lag, dass ich Workbench mit einem 'X-beliebigen Programm' verwechselte und MySQL schlussendlich doch tiefere Einarbeitung abverlangt.

Der eigentliche Client wird mein Programm sein, und das setzt eigentlich ausschliesslich auf Delphis VCL auf. Mit der DB hat es eigentlich gerade mal soviel zu tun, dass es sich von da benötigte Daten holen und nach deren Bearbeitung wieder dahin zurückschreiben soll. Die Komplexität der Daten und deren Umfang lassen aber die Verwendung einer DB als sehr ratsam erscheinen.

In der DB selbst kann ich ausser einigen sehr wenigen Testdaten (die ein Zeichensatzproblem zutage brachten), nichts verlieren.
Das mit der kompletten Neuinstallation hatte ich schonmal. MySQL war als Dienst installiert und startete irgendwann nicht mehr, und ich wusste nicht, warum. Eine Neuinstallation war erst erfolgreich, nachdem ich unter Win7 das Verzeichnis ProgrammData (nicht Programme) gelöscht hatte.
Aus Workbench heraus lässt sich MySQL ja beenden und wieder hochfahren. Wahrscheinlich habe ich da einen Eintrag in einer Systemtabelle ausgelöst, den aber nicht mehr gelöscht (bzw. den Server wieder hochgefahren). So hat Windows offensichtlich den Server gestartet(wie es die 'Dienstanweisung' vorsieht), und Workbench (bzw. der Eintrag in der Systemtabelle) hat ihn wieder heruntergefahren...

Gruss
Delbor

[himitsu]

Hast du es denn mal mit DROP TABLE versucht?



Und was passiert eigentlich, wenn man versucht eine Tabelle zu erstellen, wo schon eine gleichnamige Tabelle mit anderen Feldern/Spalten existiert?

[Delbor]

Hi himitsu

Ja. Erstmal hab ich allerdings versucht, die Tabellen anzuzeigen. Die Abfrage lieferte 0 Rows zurück.
Etwas erfolgreicher war danach Drop Database - das Resultat war zwar auch 0, aber nac der Abfrage...
Show Database lieferte den Fehler 'unbekannt...' zurück.
Und als ich jetzt versuchte, mein DB-Modell erstellen zu lassen, hatte ich wieder die Ausgangssituation - die nicht erstellte Tabelle ist wiederum die Bilddatentabelle und die Interselektionstabellen zweier n:m-Beziehungen.

Der Code selbst war ja von Workbench erstellt worden - bzw. vom Server selbst. Die entsprechende Syntax selbst kann ja kaum fehlerhaft sein. Den gibt es ja seit Jahren, und daher dürfte er wohl milliardenfach erprobt sein.

Allerdings hatte ich den 5 von mir erstellten Tabellen jeweils alle vorgesehenen Felder zugewiesen, bevor ich die Beziehungen einzeichnete. die von Workbench eingefügten Fremd- und Sekundärschlüssel wurden auf diese Weise der Felderliste angehängt.

Die fragliche BilddatenTabelle besteht aus 3 Feldern - dem zusammengesetzten Primärschlüssel (AutoincFeld(int), Typfeld(VARCHAR(3) und dem Feld Bilddaten(LONGBLOB).
Der Hintergrund ist, dass es von jedem Bild bis zu drei Formate geben kann: das originale RAW-Format (das Original, enthält auch EXIF-Daten), ein Thumbnail(evtl. PNG o. jpeg) und eine Bitmap zur grafischen Bearbeitung(Weissabgleich etc, Umwandlung in Webtaugliches Jpeg).

Inzwischen vermute ich den Fehler an zwei möglichen Stellen:

1. Das AutoincFeld und das Typfeld bilden zusammen den Primärschlüssel, sind aber aufgrund der Erstellungsfolge auf den Anfang und das Ende der Feldliste veteilt.
2. Allenfalls ist für den Fehler auch der VARCHAR-Typ des Typfeldes verantwortlich - alle anderen Schlüssel sind integer

Etwas irritiert hat mich lange Zeit, dass die eine Interselektionstabelle 5 Schlüsselfelder enthält. Da ich aber trotz intensiven Suchens (Google, diverse Foren,MySQL.de) und einer Konzeptdiskussion keinen Hinweis auf eine negative Auswirkung auf die Performance durch mehrfach zusammengesetzte Schlüssel finden konnte, hab ich diesen Punkt fürs erste als erledigt abgehakt.

Gruss
Delbor

PS:

Zitat:

Und was passiert eigentlich, wenn man versucht eine Tabelle zu erstellen, wo schon eine gleichnamige Tabelle mit anderen Feldern/Spalten existiert?

Ich hab keine gleichnamigen Tabellen mit unterschiedlichen Feldern

[Delbor]

Hi zusammen

Kürzlich bin ich in meinem neuen 'schlauen Buch' über einen kurzen, eher unscheinbaren Eintrag gestolpert. Danach sind zusammengesetzte Primärschlüssel, die ausser int auch andere Datentypen aufweisen, unter InnoDB nicht möglich.
So habe ich denn das Typfeld in der Bilddatentabelle(VARCHAR), die ja Teil des Primärschlüssels war, durch 3 Blobfelder für die verschiedenen Formate ersetzt.
Und siehe da - alle Tabellen wurden anstandslos erstellt....

Ein weiterer Punkt, den ich hier erwähnen möchte, betrifft die Speicherengine. MySQL verdankt seinen Ruf, schnell zu sein, der Engine MyIsam, verwendet aber standardmässsig heute die vielseitigere InnoDB...

Gruss
Delbor

[Sir Rufo]

Zitat von Delbor:

Kürzlich bin ich in meinem neuen 'schlauen Buch' über einen kurzen, eher unscheinbaren Eintrag gestolpert. Danach sind zusammengesetzte Primärschlüssel, die ausser int auch andere Datentypen aufweisen, unter InnoDB nicht möglich.

So ist die Aussage nicht korrekt. Unter innoDB kann man ohne weiteres ein INT und VARCHAR Feld als PRIMARYKEY setzen.

Es ist allerdings fragwürdig, dieses in Zusammenhang mit einem AUTOINC (INT) Feld. Denn dieses Feld ist ja durch den automatisch vergebenen Wert eindeutig. Durch das weitere Feld wird es nicht eindeutiger. Also ist das nur überflüssiger Ballast für den PRIMARY KEY.