Welcher Spaltentyp für hexadezimalen Farbwert? (mysql)

[split.s]

Ich möchte hexadezimale Farbwerte in einer mySQL-Datenbank abspeichern. Da es sich um sehr viele Farbwerte handelt (ca. 85 pro Datensatz) möchte ich auch einen möglichst performanten Datentyp verwenden.
Gibt es hier etwas geeigneteres außer Varchar?

[Der Martin]

Hi,

Ich möchte hexadezimale Farbwerte in einer mySQL-Datenbank abspeichern. Da es sich um sehr viele Farbwerte handelt (ca. 85 pro Datensatz) möchte ich auch einen möglichst performanten Datentyp verwenden.

kommt sehr drauf an, wie (womit) du die gespeicherten Farbwerte wieder lesen und verarbeiten willst. Ich vermute, du greifst mit PHP darauf zu und erzeugst damit dynamisch CSS. Dann werden Farbangaben, auch wenn die hexadezimale Notation letztendlich einen Zahlenwert repräsentiert, als String mit 6 (oder 3) Zeichen übergeben. Also wäre IMHO jede andere Form der Speicherung ungünstig, weil du dann wieder umwandeln müsstest.

So long,
 Martin

[split.s]

Angenommen ich speichere den Wert per HEX('4996ba') in einem SMALLINT UNSIGNED.
mySQL besitzt doch sicherlich schon eine hauseigene Funktion um das wider umzukehren oder?

[ChrisB]

Hi,

Angenommen ich speichere den Wert per HEX('4996ba') in einem SMALLINT UNSIGNED.

Wie dedlfix schon anmerkte, war SMALLINT mit 2 Byte natürlich zu kurz gegriffen, 3 Byte müssen es sein, also UNSIGNED MEDIUMINT.

mySQL besitzt doch sicherlich schon eine hauseigene Funktion um das wider umzukehren oder?

Manual lesen:
http://dev.mysql.com/doc/refman/5.1/en/mathematical-functions.html#function_conv

MfG ChrisB

[ChrisB]

Hi,

Ich möchte hexadezimale Farbwerte in einer mySQL-Datenbank abspeichern. Da es sich um sehr viele Farbwerte handelt (ca. 85 pro Datensatz) möchte ich auch einen möglichst performanten Datentyp verwenden.
Gibt es hier etwas geeigneteres außer Varchar?

UNSIGNED SMALLINT.

MfG ChrisB

[split.s]

Hi,

Ich möchte hexadezimale Farbwerte in einer mySQL-Datenbank abspeichern. Da es sich um sehr viele Farbwerte handelt (ca. 85 pro Datensatz) möchte ich auch einen möglichst performanten Datentyp verwenden.
Gibt es hier etwas geeigneteres außer Varchar?

UNSIGNED SMALLINT.

MfG ChrisB

Wie soll ich denn dort einen hexadezimalen Farbwert wie 4996ba unterbringen? Muss ich da vorher irgendwie einen dezimalen Wert draus erzeugen und wie lässt sich das wieder umkehren????

[dedlfix]

Hi!

Bitte zitiere nicht einfach alles, sondern nur das worauf du dich beziehst, und davon nur soviel, dass man deine Antwort leicht einordnen kann.

UNSIGNED SMALLINT.
Wie soll ich denn dort einen hexadezimalen Farbwert wie 4996ba unterbringen? Muss ich da vorher irgendwie einen dezimalen Wert draus erzeugen und wie lässt sich das wieder umkehren????

Die Frage muss vermutlich lauten, wie man einen Stringdarstellung eines Zahlenwertes, worunter auch hexadezimale fallen, in eine Zahl bekommt und wieder zurück. Ersteres mit Parsen, zweiteres mit Formatieren. Alles Aufwand, der vermutlich in keinem guten Verhältnis zur Speichersparnis steht.

Lo!

[ChrisB]

Hi,

Die Frage muss vermutlich lauten, wie man einen Stringdarstellung eines Zahlenwertes, worunter auch hexadezimale fallen, in eine Zahl bekommt und wieder zurück. Ersteres mit Parsen, zweiteres mit Formatieren. Alles Aufwand, der vermutlich in keinem guten Verhältnis zur Speichersparnis steht.

Auch eine dezimale Angabe 4711 ist eine „formatierte” Darstellung der internen binären Repräsentation dieser Zahl.

Ob du das DBMS oder die verarbeitende Stelle nun zur Basis 10 oder 16 formatieren/umwandeln lässt, sollte m.E. weniger ins Gewicht fallen.

MfG ChrisB

[dedlfix]

Hi!

Die Frage muss vermutlich lauten, wie man einen Stringdarstellung eines Zahlenwertes, worunter auch hexadezimale fallen, in eine Zahl bekommt und wieder zurück. Ersteres mit Parsen, zweiteres mit Formatieren. Alles Aufwand, der vermutlich in keinem guten Verhältnis zur Speichersparnis steht.
Auch eine dezimale Angabe 4711 ist eine „formatierte” Darstellung der internen binären Repräsentation dieser Zahl.
Ob du das DBMS oder die verarbeitende Stelle nun zur Basis 10 oder 16 formatieren/umwandeln lässt, sollte m.E. weniger ins Gewicht fallen.

Es es ist dann doch weniger aufwendig, als ich mir erst vorgestellt hatte. Mit beispielsweise X'4996ba' lässt sich ein HEX-Wert notieren und mit HEX(spalte) wieder ausgeben. Das klappt mit jeder Spalte, die 3 Byte speichern kann, also CHAR(3), BINARY(3) und VARCHAR(3) und UNSIGNED MEDIUMINT.

Man muss nun noch sicherstellen, dass sich der in Richtung MySQL übergebene Wert hexadezimal interpretieren lässt, sonst gibt es einen Syntaxfehler.

Lo!

[ChrisB]

Hi,

Mit beispielsweise X'4996ba' lässt sich ein HEX-Wert notieren und mit HEX(spalte) wieder ausgeben. Das klappt mit jeder Spalte, die 3 Byte speichern kann, also CHAR(3), BINARY(3) und VARCHAR(3) und UNSIGNED MEDIUMINT.

Wobei UNSIGNED MEDIUMINT mir immer noch am geeignetsten erscheint.

Mit HEX() geben zwar, wie du schon sagst, alle das gewünschte zurück - aber wenn ich mir die Tabelle bspw. über phpMyAdmin anschaue, dann sehe ich bei den drei erstgenannten nur Zeichensalat, und bei letzterem wenigstens noch einen Zahlenwert, wenn auch Dezimal an der Stelle.

Und dieser Zeichensalat kann dann auch bspw. den Export „schwierig” machen; pma liefert mir für meine Tabelle

CREATE TABLE `hextest` (  
  `h1` char(3) character set ascii NOT NULL,  
  `h2` varchar(3) character set ascii NOT NULL,  
  `h3` binary(3) NOT NULL,  
  `h4` mediumint(9) NOT NULL  
) ENGINE=MyISAM DEFAULT CHARSET=utf8;  
  
--  
-- Daten für Tabelle `hextest`  
--  
  
INSERT INTO `hextest` (`h1`, `h2`, `h3`, `h4`) VALUES  
('I??', 'I??', 'I��', 4822714);

Dieses INSERT-Statement ist prädestiniert dafür, anschliessend Probleme zu machen.

MfG ChrisB

[dedlfix]

Hi!

Mit HEX() geben zwar, wie du schon sagst, alle das gewünschte zurück - aber wenn ich mir die Tabelle bspw. über phpMyAdmin anschaue, dann sehe ich bei den drei erstgenannten nur Zeichensalat, und bei letzterem wenigstens noch einen Zahlenwert, wenn auch Dezimal an der Stelle.

h1 char(3) character set ascii NOT NULL,
  h2 varchar(3) character set ascii NOT NULL,

ASCII ist ja auch keine 1-Byte-Kodierung sondern üblicherweise eine Halb-Byte-Kodierung. Da würde ich keine korrekten Ergebnisse erwarten, auch wenn ich jetzt nicht genau weiß, wie MySQL mit ASCII umgeht. Nicht definierte Zeichen in UTF-8/Unicode umzuwandeln, sollte jedenfalls schwierig sein.

INSERT INTO hextest (h1, h2, h3, h4) VALUES
('I??', 'I??', 'I��', 4822714);[/code]
Dieses INSERT-Statement ist prädestiniert dafür, anschliessend Probleme zu machen.

Dafür kennt mein PMA die Checkbox "Use hexadecimal for binary fields", die bei mir per Default angehakt war.

Lo!

[dedlfix]

Hi!

Ich möchte hexadezimale Farbwerte in einer mySQL-Datenbank abspeichern.
UNSIGNED SMALLINT.

Wenn dann UNSIGNED MEDIUMINT, SMALLINT hat nur 2 Byte. (Integers hab ich für meine Aufzählung gar nicht in Betracht gezogen, weil ich von 1,2,4,8 ausging. Dass es MEDIUMINT mit 3 Byte gibt, ... wunderte mich dann doch, als ich nochmal nach deinem SMALLINT schaute.)

Data Type Storage Requirements

Lo!

[ChrisB]

Hi,

Wenn dann UNSIGNED MEDIUMINT, SMALLINT hat nur 2 Byte.

My bad, natürlich 3 Byte.

MfG ChrisB

[dedlfix]

Hi!

Ich möchte hexadezimale Farbwerte in einer mySQL-Datenbank abspeichern. Da es sich um sehr viele Farbwerte handelt (ca. 85 pro Datensatz) möchte ich auch einen möglichst performanten Datentyp verwenden.
Gibt es hier etwas geeigneteres außer Varchar?

Ein VARCHAR mit einer 1-Byte-Kodierung benötigt 1 Byte pro Zeichen plus 1 Längenbyte.
Ein CHAR mit einer 1-Byte-Kodierung benötigt 1 Byte pro Zeichen.
Ein BINARY der Länge 3 benötigt 3 Byte

Wenn du also Farbwerte als 6 Zeichen ablegen willst, kommst du mit CHAR (in Latin1) nicht günstiger. Wenn du direkt Hex-Werte nimmst, passt ein Farbwert in 3 Byte - dann am besten BINARY.

Allerdings sind die paar Byte nun wirklich nicht mehr das Problem. Bedenke, dass du mit der Binärdarstellung auch einen höheren Aufwand hast, die Werte in Textform zu bringen, gegebenenfalls auch beim Umkehrvorgang (zumindest einmalig beim Einpflegen).

Lo!