Ich habe mich in letzer Zeit ziemlich viel mit dem MySQL Workbench beschäftigt. Vor allem für das Datenbank Design meines kleinen Privat Projektes, das ich hier wohl bald mal Vorstellen werde. Ich habe früher sehr gern mit dem DBDesinger 4 gearbeitet und seine Features zu schätzen gelernt. Im OpenSource und Freeware Bereich gab es eigentlich keine Konkurrenz für ihn.
Bis dann die MySQL AB auf die Idee gekommen ist, den Entwickler anzustellen und eine eigene Software zur Datenmodellierung zu erstellen. Eigentlich keine Schlechte Idee, der Entwickler verdient nun sein Geld mit dem was er vorher in seiner Freizeit gemacht hat. Nur das Problem ist nun MySQL, jetzt SUN, will ja auch Geld verdienen. Also gibt es eine Kommerzielle Lösung und eine OpenSource Lösung.
Und aus meiner Sicht sind ein Großteil der tollen Features des DBDesinger nur in die Kommerzielle Variante aufgenommen wurden. Wie z.B. die Synchronisation mittels Verbindung zum Datenbank Server. Außer dem ist mir noch aufgefallen, das die von mir relativ häufig genutzte Funktion, beim Exportieren des Schemas, das Ignorieren von “Foreign Keys” oder um genauer zu sein das nicht mit aufnehmen derer in die SQL Datei.
Viele Werden jetzt sagen, warum denn “Foreign Keys” nutzen aber nicht in das Schema einbauen. Ich nutze Foreign Keys im Design wirklich nur um die Verbindungen zwischen den Tabellen dazustellen und sichere dann über Programmierlogik die Integrität der Daten in der Datenbank. Das ist für mich persönlich die bessere Lösung im Bereich Webentwicklung.
Also MySQL Workbench ist schon mal ein guter Schritt in die Richtige Richtung, aber kann noch viele Schritte in diese Richtung vertragen. Wenn er wirklich an alle alten Features des DBDesinger herankommt werde ich evtl. sogar überlegen mir die Kommerzielle Variante zuzulegen.
Und für die die evtl. dem DBDesinger noch eine Chance geben wollen, auf Sourceforge hat sich eine Truppe rangemacht einen Fork weiter zu führen, aber dort ist die Aktivität auch schon extrem gesunken.
Neben dem Spickzettel für die MySQL Integer Größe habe ich mir nun noch ein für die MySQL TEXT/BLOB Größe gemacht.
CHAR / BINARY
Größe festgelegt durch die Anzahl der Zeichen, aber maximal 255 Zeichen.
Also immer ein Festwert, egal ob gefüllt, halb gefüllt oder leer.
VARCHAR / VARBINARY
Definierte Feldgröße: * von 0-255 Zeichen: Anzahl der Zeichen + 1 Byte * von 256-65532 Zeichen Anzahl der Zeichen + 2 Byte
Also ein VARCHAR (500) brauch für das abspeichern von “abcd” ein Byte mehr Platz als ein VARCHAR (200).
TINYTEXT / TINYBLOB
Größe: < 2 8 Byte (+ 1 Byte MySQL)
daraus ergibt sich max. 255 (Ein-Byte1 ) Zeichen
TEXT / BLOB
Größe: < 2 16 Byte (+ 2 Byte MySQL )
daraus ergibt sich max. 65535 (Ein-Byte1 ) Zeichen oder ungefähr 64 KByte
MEDIUMTEXT / MEDIUMBLOB
Größe: < 2 24 Byte (+ 3 Byte MySQL)
daraus ergibt sich max. 16777216 (Ein-Byte1 ) Zeichen oder ungefähr 16 MB
LONGTEXT / LONGBLOB
Größe: < 2 32 Byte (+4 Byte MySQL)
daraus ergibt sich max. 4294967296 (Ein-Byte1 ) Zeichen oder ungefähr 4 GB
1 Ein Byte Zeichen deswegen weil sich die Anzahl der Zeichen bei Unicode-/Nicht ASCII-Zeichen entsprechend verringert.
- 1 Byte je Zeichen benutzt das normale Latin
- 2 Byte je Zeichen benutzen die meisten Europäischen Sprachen mit Umlauten, Akzenten usw.
- 3 Byte je Zeichen werden nur von chinesischen , koreanischen und japanischen Schriftzeichen benutzt.
Daraus folgt in einem Normalen “TEXT” können “nur” 21845 Chinesische oder 32767 “Normale” Nicht ASCII Zeichen untergebracht werden. Deswegen nochmal die Angabe in Byte
Vor kurzem habe ich ein guten Blogeintrag über das Erfassen von Änderungen eines Datenbankschemas in einem Versioniserungssystem wie Subversion.
Links:
So damit ich es mir endlich mal merke und nicht jedes mal nach schauen muss habe ich hier mal die 5 Integer Felder der MySQL Datenbank in einer Kurzzusammenfassung zusammengestellt mit Namen, dem Wertebereich für Vorzeichen behaftet (signed) und ohne Vorzeichen (unsigned).
TINYINT
Größe: 8 Bit
signed: von -128 bis 127
unsigned: von 0 bis 255
SMALLINT
Größe: 16 Bit
signed: von -32768 bis 32767
unsigned: von 0 bis 65535
MEDIUMINT
Größe: 24 Bit
signed: von -8388608 bis 8388607
unsigned: von 0 bis 16777215
INT oder INTEGER
Größe: 32 Bit
signed: von -2147483648 bis 2147483647
unsigned: von 0 bis 4294967295
BIGINT
Größe: 64 Bit
signed: von -9223372036854775808 bis 9223372036854775807
unsigned: von 0 bis 18446744073709551615
Arithmetische Funktionen sollte nicht auf BIGINTs die selbst größer 63 Bit (9223372036854775807) sind oder deren Ergebnisse größer der besagten 63 Bit sind angewendet werden, da sonst Rundungsfehler auftreten können ,da MySQL dann mit DOUBLE werten arbeitet
