MySQL Workbench

[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.

[Delbor]

Hi Sir Rufo

Danke für deine Antwort! Es ist möglich, dass die entsprechende Passage in dem Buch für den PrimaryKey den AutoInc voraussetzte und ich diese Tatsache einfach überlesen habe.

Ich habe allerdings bemerkt, dass es MySQL offenbar kalt lässt, dass ich die Zeichensatz-Einstellungen von utf8 auf latin1 wändert habe - mit meinem Programm eingefügte Strings kommen nach wie vor als 'verunstaltete' Zeichhenfolgen daher.

Mit einer früheren Version von MySQL(aber auch 5.x) hatte ich die SQL-Stringvariable jeweils als Widestring definiert (D7). Das ist offenbar unter der aktuelllen Version nicht mehr gültig.

Gruss
Delbor

[Bernhard Geyer]

Zitat von Delbor:

Ich habe allerdings bemerkt, dass es MySQL offenbar kalt lässt, dass ich die Zeichensatz-Einstellungen von utf8 auf latin1 wändert habe - mit meinem Programm eingefügte Strings kommen nach wie vor als 'verunstaltete' Zeichhenfolgen daher.

Welche Zeichensatzeinstellung? Für das DBMS? Für die DB? Für die einzelne Tabelle? Für deine Connection?

[mkinzler]

Zitat:

Es ist möglich, dass die entsprechende Passage in dem Buch für den PrimaryKey den AutoInc voraussetzte

Ohne autoinc muss das Feld auf jeden Fall gesetzt werden. Für einen ( künstlichen) PK ist autoinc eine gute Option.

Zitat:

Ich habe allerdings bemerkt, dass es MySQL offenbar kalt lässt, dass ich die Zeichensatz-Einstellungen von utf8 auf latin1 wändert habe

Oder der Zugriffskomponente

[Delbor]

Hi zusammen

Zitat von mkinzler:

Ich habe allerdings bemerkt, dass es MySQL offenbar kalt lässt, dass ich die Zeichensatz-Einstellungen von utf8 auf latin1 wändert habe

Oder der Zugriffskomponente[/QUOTE]

Der Zugriffskomponente? Da gibt's bei mir gerade mal die TSQL-Connection, TSQLDataset und TDatasource als Verbindung zu einem DB-Grid.
In einem Beispiel zu DBExpress emppfiehlt Embarcadero zwar eine 'Schlange' aus den Komponenten TSQLConnection,TSQLDataset, (TDatasource*), TClientDataSet und TDataSetProvider, die ich aber nicht verwende - ich habs mal versucht, aber irgendwie nicht die richtige Reihenfolge beim setzen der Propertys/nicht die richtige Komponente zum setzen eines/der Propertys erwwischt.
Seither begnüge ich mich mit den zuerst genannten 3 Komponenten. Und die bieten keine speziellen Propertys zum setzen des Zeichensatzes an, soweit ich gesehen habe.
Nach diesen Erklärungen ist dies aber auch gar nicht nötig - es ist letzlich so oder so eine Frage der Variablendeklaration..
Widerspruch wird gerne entgegengenommen.

Zitat:

Welche Zeichensatzeinstellung? Für das DBMS? Für die DB? Für die einzelne Tabelle? Für deine Connection?

Hmm, sehr gute Frage. Beim Erstellen des DB-Modells in MySQL-Workbench stelle ich die Sortierfolge (Collation) der Tabellen immer auf latin1-swedish_ci ein - damit ist der Zeichensatz automatisch latin1. Soweit ich die Hilfen richtig interpretiert habe (die sind in Workbench alle englisch), ist der Zeichensatz des MySQL-Servers standardmässig utf8 - und latin1 soll damit kompatibel sein. Der (Default-)Zeichensatz der DB selbst sollte eigentlich auch latin1 sein. Sollte er undefiniert sein, gilt für die DB m.W. die Einstellung des Servers. Entscheidend ist aber letztlich die Einstellung der Tabelle, respektive der Spalten (nicht-Var-Spalten können in Workbench gar keine Collations zugewiesen werden).
Den Zeichensatz der Connection (nicht Delphis TConnection-Komponente) sollte auch latin1 sein, aber das müsste ich nochmal überprüfen.


(*) Die wird m.W. da auch nur benötigt, wenn die SQL-Abfrage kein eigenes Grid zur Datenausgabe erzeugt.

Gruss
Delbor