nicht angemeldet Marc Reichelt
Marc Reichelt
dedlfix
dedlfix
dedlfix
dedlfix
dedlfix
Betrifft mySQL
Wieviel Bytes hat der Spaltentyp ENUM eigentlich?
Habe mal irgendwo gelesen, dass intern ein TINYINT-Index vergeben der nur 1-2 Bytes hat und der sich den Name aus einem Hash holt. Kann mir jemand das bestätigen oder mich eines besseren belehren?
Liebe Grüße
Hallo split.s,
Wieviel Bytes hat der Spaltentyp ENUM eigentlich?
Habe mal irgendwo gelesen, dass intern ein TINYINT-Index vergeben der nur 1-2 Bytes hat und der sich den Name aus einem Hash holt. Kann mir jemand das bestätigen oder mich eines besseren belehren?
Er hat zwei Bytes laut der offiziellen Dokumentation zu enum - von einem Hash steht dort nichts, aber eventuell wird dies intern so realisiert.
Grüße
Marc Reichelt || http://www.marcreichelt.de/
Hello,
von einem Hash steht dort nichts, aber eventuell wird dies intern so realisiert.
Warum sollte es einen Hash geben? Der binäre Wert der Spalte ist doch bereits der Index in die Liste
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hallo Tom,
»» von einem Hash steht dort nichts, aber eventuell wird dies intern so realisiert.
Warum sollte es einen Hash geben? Der binäre Wert der Spalte ist doch bereits der Index in die Liste
Weil du die Zuordnung String => Integer effizient umsetzen musst.
Angenommen du hast n = 60000 mögliche Strings, so musst du im schlimmsten Fall alle n Elemente durchgehen, bis du deinen binären Wert hast - also mit einer Laufzeit von O(n). Bei einem Hash beträgt die Laufzeit im Idealfall O(1), bei einer geringen Anzahl von Kollisionen.
Grüße
Marc Reichelt || http://www.marcreichelt.de/
Hello,
Weil du die Zuordnung String => Integer effizient umsetzen musst.
So herum gesehen wäre es logisch.
Dann müssten ja drei Listen geführt werden
gewünschte Reihenfolge der Einträge
Index -> Klartext
Hashcode -> Klartext -> Index
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
echo $begrüßung;
» » von einem Hash steht dort nichts, aber eventuell wird dies intern so realisiert.
» Warum sollte es einen Hash geben? Der binäre Wert der Spalte ist doch bereits der Index in die Liste
Weil du die Zuordnung String => Integer effizient umsetzen musst.
Ein zweibytiger Hashwert erscheint mir nicht ausreichend kollisionssicher.
Angenommen, es würden Hash-Werte verwendet, so müssen diese trotzdem mit der Liste der erlaubten (Hash-)Werte verglichen werden, um keine ungültigen Hash-Werte abzulegen. Ein Durchsuchen der Liste ist also in beiden Fällen notwendig.
Das Handbuch schreibt im Gegensatz zu Hash recht häufig von Index und nummerischer Position (ENUM('foo','bar') ergibt foo=1, bar=2). Werden die Werte in einen nummerischen Kontext gebracht, wird diese Position zurückgegeben.
Und in der Tat (ich hab nachgesehen) wird der Wert als Position und nicht als Hash abgelegt.
echo "$verabschiedung $name";
Hello,
Und in der Tat (ich hab nachgesehen) wird der Wert als Position und nicht als Hash abgelegt.
In der Nachschlageliste oder in der Datentabelle?
Marc ging es ja wohl um die Organisation der Nachschlageliste.
Die ist, dazu hatte ich gestern einen interessanten experiementellen Beitrag gefunden im Web http://www.dp.cx/?p=1020 (der mich zum weiterexperimentieren angeregt hat), auf jeden Fall in der gewünschten Reihenfolge der Klartexte sortiert. Diese Information muss also irgendwie signiert sein, am einfachsten Falle eben dadurch, dass man die Werte in der gewünschten Reihenfolge in die Liste aufnimmt.
Wenn sie nun auch noch schnell durchsuchbar sein soll, muss über die Klartexte ein Index oder Hash vorliegen, also entweder eine Baumstruktur (Hash, BTree ist hier glaube ich in Verwendung) oder eben eine sortierte Liste (das würde das Update erschweren, weil beim Einfügen alle Namen verschoben werden müssen).
Aber im Moment verzweifele ich gerade mal wieder an der Abstimmung der Character-Sets zwischen MySQL-Bluebox auf WinXP und der MySQL-Xampp Version...
Gibts dazu eigentlich schon einen Artikel aus berufener Quelle, wie man es machen muss?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hello,
1. wenn die Nachschlageliste mittels ALTER-Statement geändert wird,
wird der Index neu vergeben und die gesamte Tabelle wird überarbeiet.
2. es ist möglich, gleiche Klartexte in die Liste einzutragen.
Bei einem Insert in die Tabelle wird dann der erste dazu passende Index
gewählt.
3. Der Fehler beim Insert ist immer noch vorhanden
mysql> insert into enumtest set val ='9';
Query OK, 1 row affected (0.00 sec)
mysql> select * from enumtest;
+----+----------------+
| id | val |
+----+----------------+
| 1 | zwanzig |
| 2 | dreißig |
| 3 | vierzig |
| 4 | dreiunddreißig |
| 5 | vierzig |
+----+----------------+
5 rows in set (0.00 sec)
'vierzig' hat den Index 9.
Eigentlich hätte der Eintrag abgelehnt werden müssen:
mysql> insert into enumtest set val ='dreizehn'; -- dreizehn ist nicht in der Liste
Query OK, 1 row affected, 1 warning (0.00 sec)
mysql> select * from enumtest;
+----+----------------+
| id | val |
+----+----------------+
| 1 | zwanzig |
| 2 | dreiáig |
| 3 | vierzig |
| 4 | dreiunddreiáig |
| 5 | vierzig |
| 6 | |
+----+----------------+
6 rows in set (0.00 sec)
mysql> select id, val+0 from enumtest;
+----+-------+
| id | val+0 |
+----+-------+
| 1 | 4 |
| 2 | 6 |
| 3 | 9 |
| 4 | 7 |
| 5 | 9 |
| 6 | 0 |
+----+-------+
6 rows in set (0.00 sec)
Das gibt zwar immer noch keine Auskunft über die innere Verwaltung der enumm-Klartexte, aber bei einem so dämlichen und fehleranfälligen Verhalten eines Datenbanksystems, das inzwischen Version 5.1 erreicht hat (und an 6.0 bastelt), mag ich nicht glauben, dass die hier eine intelligente Lösung drin haben.
Ergo: die enum-Verwaltung könnte für Version 6.0 wirklich überarbeiet werden!
MMn sollte der Eintrag des Datensatzes bei einem verkehrten enum-Wert abgelehnt werden
und eine entsprechende Fehlermeldung bereitgestellt werden.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
echo $begrüßung;
- Der Fehler beim Insert ist immer noch vorhanden
Wieso? Arbeitet doch so wie es dokumentiert ist.
echo "$verabschiedung $name";
Hello,
echo $begrüßung;
- Der Fehler beim Insert ist immer noch vorhanden
Wieso? Arbeitet doch so wie es dokumentiert ist.
Bitte um den Link, damit wir vom Gleichen reden :-)
Dann ist also schon das Design falsch oder besser _immer__noch_!
Man muss sich also immer noch daran halten, keine numerisch aussehenden Werte in die Enumeration aufzunehmen, sonst gibt es später Verarbeitungsfehler.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
echo $begrüßung;
» » 3. Der Fehler beim Insert ist immer noch vorhanden
» Wieso? Arbeitet doch so wie es dokumentiert ist.
Bitte um den Link, damit wir vom Gleichen reden :-)
http://dev.mysql.com/doc/refman/5.1/en/enum.html
If you store a number into an ENUM column, the number is treated as the index into the possible values, and the value stored is the enumeration member with that index. [...] If the numeric value is quoted, it is still interpreted as an index if there is no matching string in the list of enumeration values. For these reasons, it is not advisable to define an ENUM column with enumeration values that look like numbers, because this can easily become confusing.
echo "$verabschiedung $name";
Hello,
» » 3. Der Fehler beim Insert ist immer noch vorhanden
» Wieso? Arbeitet doch so wie es dokumentiert ist.
Bitte um den Link, damit wir vom Gleichen reden :-)http://dev.mysql.com/doc/refman/5.1/en/enum.html
If you store a number into an ENUM column, the number is treated as the index into the possible values, and the value stored is the enumeration member with that index. [...] If the numeric value is quoted, it is still interpreted as an index if there is no matching string in the list of enumeration values. For these reasons, it is not advisable to define an ENUM column with enumeration values that look like numbers, because this can easily become confusing.
Ja, das kenne ich und genau das bezeichne ich als Design-Fehler!
Wer denkt sich so einen Schwachsinn aus?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
echo $begrüßung;
» Und in der Tat (ich hab nachgesehen) wird der Wert als Position und nicht als Hash abgelegt.
In der Nachschlageliste oder in der Datentabelle?
In der .MYD-Datei einer Tabelle.
Marc ging es ja wohl um die Organisation der Nachschlageliste.
Die Werte werden in den Metadaten der Tabelle abgelegt sein. Der Parser wird beim Parsen der Statements den Stringwert in den Positionswert umrechnen. Alles andere erscheint mir auch nicht besonders sinnvoll.
Die ist, dazu hatte ich gestern einen interessanten experiementellen Beitrag gefunden im Web http://www.dp.cx/?p=1020 (der mich zum weiterexperimentieren angeregt hat),
Da steht auch nicht weiter interessantes drin, das nicht schon im Handbuch steht.
auf jeden Fall in der gewünschten Reihenfolge der Klartexte sortiert.
Von ener Enumeration erwartet man im Allgemeinen eine Reihenfolge, so wie die Werte angeführt sind oder wie ihnen explizit ein Zahlenwert zugeordnet ist. Eine Sortierung nach dem ASCIIbet ist meist nicht gefragt.
Wenn sie nun auch noch schnell durchsuchbar sein soll, muss über die Klartexte ein Index oder Hash vorliegen, also entweder eine Baumstruktur (Hash, BTree ist hier glaube ich in Verwendung) oder eben eine sortierte Liste (das würde das Update erschweren, weil beim Einfügen alle Namen verschoben werden müssen).
Bei einer Enumeration werden keine Klartexte gespeichert. Sie dienen nur der einfacheren Handhabung. Das ist ja gerade ihr Sinn, mit wenig Speicherplatz eine Information aus einem eingeschränkten Wertebereich aufzubewahren, die im Klartext deutlich länger ist.
Aber im Moment verzweifele ich gerade mal wieder an der Abstimmung der Character-Sets zwischen MySQL-Bluebox auf WinXP und der MySQL-Xampp Version...
Gibts dazu eigentlich schon einen Artikel aus berufener Quelle, wie man es machen muss?
Was konkret?
echo "$verabschiedung $name";
Hello,
Bei einer Enumeration werden keine Klartexte gespeichert. Sie dienen nur der einfacheren Handhabung. Das ist ja gerade ihr Sinn, mit wenig Speicherplatz eine Information aus einem eingeschränkten Wertebereich aufzubewahren, die im Klartext deutlich länger ist.
Ist ja ulkig. Wenn die nicht gespeichert werden, woher weiß das System dann, zu welchem Index welcher Klartext gehört? Das ist mir nun aber schleierhaft.
#-------
Aber im Moment verzweifele ich gerade mal wieder an der Abstimmung der Character-Sets zwischen MySQL-Bluebox auf WinXP und der MySQL-Xampp Version...
Gibts dazu eigentlich schon einen Artikel aus berufener Quelle, wie man es machen muss?Was konkret?
echo "$verabschiedung $name";
Wie muss mit der Konsole (Bluebox, Blackbox) und der Datenbank zusammenarbeiten, dass die Codierungen nicht durcheinandergewürfelt werden.
Ich kann zwar im Moment über die Konsole Werte eintragen in die Tabelle. das scheint auch richtig zu funktionieren. Aber sie werden mir beim Select als Single-Bytecodes wieder ausgegeben.
Die Konsole sagt, sie hätte CP850:
Status von Gerät CON:
---------------------
Zeilen: 500
Spalten: 120
Wiederholrate: 31
Verzögerungszeit:1
Codepage: 850
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
echo $begrüßung;
» Bei einer Enumeration werden keine Klartexte gespeichert. Sie dienen nur der einfacheren Handhabung. Das ist ja gerade ihr Sinn, mit wenig Speicherplatz eine Information aus einem eingeschränkten Wertebereich aufzubewahren, die im Klartext deutlich länger ist.
Ist ja ulkig. Wenn die nicht gespeichert werden, woher weiß das System dann, zu welchem Index welcher Klartext gehört? Das ist mir nun aber schleierhaft.
Das kommt darauf an. In kompilierten Programmen ist der Klartext ein Bezeichner. Das Programm arbeitet aber nicht mit Bezeichnern sondern mit den dahinterstehenden Werten. Der Kompiler löst die Beziehung zwischen beiden auf. (Dass es Reflection gibt, mit der man wieder an den Bezeichner kommt, steht auf einem anderen Blatt.)
Im Falle von MySQL steht die Zuordnungsinformation bei den restlichen Metadaten der Tabelle.
Wie muss mit der Konsole (Bluebox, Blackbox) und der Datenbank zusammenarbeiten, dass die Codierungen nicht durcheinandergewürfelt werden.
Du musst MySQL mitteilen, welche Kodierung du verwendest. Wenn deine Kodierung nicht mit der Default-Kodierung übereinstimmt, ist es am einfachsten, wenn du mit SET NAMES die von dir gewünschte Kodierung für die aktuelle Session angibst. MySQL kodiert dann zwischen deiner und der der Felder hin und her. Geht natürlich nicht in allen Konstellationen verlustfrei.
echo "$verabschiedung $name";
Hello,
Im Falle von MySQL steht die Zuordnungsinformation bei den restlichen Metadaten der Tabelle.
Na siehste. Hat doch gar nicht weh getan. :-)
Dann können wir nun ja mit dem Gedanken von Marc fortfahren, der meinte, dass diese Nachschlagswerte ja intelligent verwaltet werden könnten.
#------
Wie muss mit der Konsole (Bluebox, Blackbox) und der Datenbank zusammenarbeiten, dass die Codierungen nicht durcheinandergewürfelt werden.
Du musst MySQL mitteilen, welche Kodierung du verwendest. Wenn deine Kodierung nicht mit der Default-Kodierung übereinstimmt, ist es am einfachsten, wenn du mit SET NAMES die von dir gewünschte Kodierung für die aktuelle Session angibst. MySQL kodiert dann zwischen deiner und der der Felder hin und her. Geht natürlich nicht in allen Konstellationen verlustfrei.
Das habe ich gemacht, in Einzelversuchen vor, nach und während der Arbeit mit der Tabelle.
Hat aber nichts genützt.
Beim Select wird in der Windows-Konsole ("DOS-Box") immer noch Müll (UTF-8 in Bytecodedarstellung) angezeigt.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hello,
Im Falle von MySQL steht die Zuordnungsinformation bei den restlichen Metadaten der Tabelle.
Na siehste. Hat doch gar nicht weh getan. :-)
Dann können wir nun ja mit dem Gedanken von Marc fortfahren, der meinte, dass diese Nachschlagswerte ja intelligent verwaltet werden könnten.
Auf der Platte wird die Liste einfach in der gewünschten Reihenfolge in der *.frm-Datei abgelegt.
Ob nun beim Zugriff auf die Tabelle im Speicher eine Auflösung der Liste in die verschiedenen Dimensionen stattfindet, kann man so ja nocht sehen...
Aber irgendeine intelligente Lösung müssen sie sich ja doch überlegt haben, denn wenn 65.535 gültige Werte zulässig sind, für die ich noch nicht einmal eine Feldlängenbeschränkung finden konnte (für die Klartexte), dann kommen da ja ggf. auch mal 4MB Speicherbedarf zustande. Wenn man die Werte jetzt noch in eine andere Struktur (Baum) bringen wollte, können das noch 500kB mehr werden...
4,5MB nur für ein enum-Feld würden den Server schon ganz schön belasten.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hallo Tom,
Aber irgendeine intelligente Lösung müssen sie sich ja doch überlegt haben, denn wenn 65.535 gültige Werte zulässig sind, für die ich noch nicht einmal eine Feldlängenbeschränkung finden konnte (für die Klartexte), dann kommen da ja ggf. auch mal 4MB Speicherbedarf zustande. Wenn man die Werte jetzt noch in eine andere Struktur (Baum) bringen wollte, können das noch 500kB mehr werden...
4,5MB nur für ein enum-Feld würden den Server schon ganz schön belasten.
Hier geht es weniger um den Speicherplatz - denn ein enum von 4 MB Typengröße wird vermutlich nicht so oft eingesetzt.
Viel entscheidender ist es, bei häufigen Datenbankabfragen die Strings in Integer zu wandeln. Dies kann in Hashes geschehen. Wie dedlfix bereits angemerkt hat kann es aber gut sein dass hier zu viele Kollisionen entstehen - ein Trie wäre also eventuell auch keine schlechte Idee.
Egal wie wir es auch drehen: Die Verwendung von Zahlen könnte in diesem Fall einen (wenn auch eventuell geringen) Geschwindigkeitszuwachs bedeuten.
Grüße
Marc Reichelt || http://www.marcreichelt.de/
Hello Marc,
Egal wie wir es auch drehen: Die Verwendung von Zahlen könnte in diesem Fall einen (wenn auch eventuell geringen) Geschwindigkeitszuwachs bedeuten.
ich hoffe ich verstehe Dich jetzt nicht falsch.
Aber Zahlen als ENUMs kannst Du nicht benutzen, weil MySQL eben dieses merkwürdige Design hat für die ENUM-Auswertung.
Wird die Zahl in der Liste nicht gefunden, mutiert sie zum Index und dieser wird stattdessen eingetragen, unbeachtet der Tatsache, dass dieser index ja zu einer anderen Zahl der Liste gehört!
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
echo $begrüßung;
» [...] SET NAMES [...]
Das habe ich gemacht, in Einzelversuchen vor, nach und während der Arbeit mit der Tabelle.
Hat aber nichts genützt.
Zeig mir dein
show variables like 'char%';
und ich sag dir ... was auch immer mir dazu einfällt.
echo "$verabschiedung $name";
Hello,
» [...] SET NAMES [...]
Das habe ich gemacht, in Einzelversuchen vor, nach und während der Arbeit mit der Tabelle.
Hat aber nichts genützt.Zeig mir dein
show variables like 'char%';
und ich sag dir ... was auch immer mir dazu einfällt.
Ich glaub's einfach nicht. Und ich verstehe es nicht!
Nun habe ich es nochmal probiert (Server war zwischendurch runter) und nun geht es, aber egal, ob ich latin1 oder latin2 nehme...
mysql> show variables like 'char%';
+--------------------------+------------------------------------------+
| Variable_name | Value |
+--------------------------+------------------------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | C:\Programme\xampp\mysql\share\charsets\ |
+--------------------------+------------------------------------------+
8 rows in set (0.00 sec)
mysql> set names 'latin2';
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like 'char%';
+--------------------------+------------------------------------------+
| Variable_name | Value |
+--------------------------+------------------------------------------+
| character_set_client | latin2 |
| character_set_connection | latin2 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin2 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | C:\Programme\xampp\mysql\share\charsets\ |
+--------------------------+------------------------------------------+
8 rows in set (0.00 sec)
mysql> select * from enumtest;
+----+----------------+
| id | val |
+----+----------------+
| 1 | zwanzig |
| 2 | dreißig |
| 3 | vierzig |
| 4 | dreiunddreißig |
| 5 | vierzig |
| 6 | |
+----+----------------+
6 rows in set (0.00 sec)
Nun steht da plötzlich ein 'ß' usw.
Muss ich denn nun noch 'was verstellen, damit ich die Tabellen nicht demoliere?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
echo $begrüßung;
Muss ich denn nun noch 'was verstellen, damit ich die Tabellen nicht demoliere?
Zum einen ist die Angabe zur Kodierung (Kollation interessiert hier nicht) des einzelnen Feldes maßgeblich, was für Zeichen darin abgelegt werden können. Zum anderen ist MySQL darauf angewiesen, vom Client korrekt kodierte Daten geliefert zu bekommen. Die Kodierung sollte nach dem Verbindungsaufbau mit der MySQL-Client-API-Funktion mysql_set_character_set() eingestellt werden. Für die ISO-8859-Familie und UTF-8 reicht auch ein SET-NAMES-Statement (dem man den Namen der Kodierung auch ohne Anführungszeichen angeben kann).
Für die Client-zu-Server-Datenübertragung sind die Einstellungen character_set_client und character_set_connection und für den Rückweg character_set_results zuständig. Alle drei werden mit SET NAMES auf den gleichen Wert gesetzt. Es gibt auch noch SET CHARACTER SET, aber das setzt character_set_connection auf den Wert von character_set_database. Wenn character_set_connection auf Latin1 steht und man ansonsten mit UTF-8 hantiert, gibt es Datenverlust bei Nicht-Latin1-Zeichen. Das Handbuch-Kapitel Connection Character Sets and Collations beschäftigt sich mit dem Thema. (Latin1 ist nach MySQLs Auffassung übrigens Windows-1252. Besser ist's - gibt weniger Knatsch, wenn die Anwender Windows-1252 statt Latin1 senden.)
echo "$verabschiedung $name";
Hi,
Betrifft mySQL
Wieviel Bytes hat der Spaltentyp ENUM eigentlich?
so viel, wie die Dokumentation behauptet, schätze ich.
Cheatah
