nummerische ENUM Values

nummerische ENUM Values

am 26.07.2007 19:25:51 von Oliver Lehmann

Hallo,

ich verwende MySQL 5.0 - leider gibts dort keine Check-Constraints.
Ich habe das Problem, das ich Datensaetze klassifizieren moecht nach 2
Kriterien "state" und "type". Der Endanwender soll die Klassifizierungs-
merkmale in der von Ihm konfigurierten Sprache sehen. Also habe ich mir
gedacht - erlaube ich als ENUM werte nur die jeweiligen TEXTIDs unter
denen dann die Uebersetzung gepflegt wird. Z.B.

typ ENUM ('180','190')

Und dann kann man in der Text-Tabelle fuer textid 180 und 190 den Text in
seiner jeweiligen Landessprache pflegen.
Soweit zur Theorie. Um die Auloesung Textid in den Columns typ und state
zu vereinfachen will ich mir eine View basteln welche meine Tabelle direkt
mit der Text-Tabelle joint um dann gleich den Text zu den Enum-Werten mit
zu bekommen:


SELECT mcs.mur_userid
,mcs.capitalsourceid
,mcs.type
,mtx1.text typecomment
,mcs.state
,mtx2.text statecomment
,mcs.accountnumber
,mcs.bankcode
,mcs.comment
,mcs.validtil
,mcs.validfrom
FROM capitalsources mcs
,text mtx1
,text mtx2
,settings mse
WHERE mse.name = 'displayed_language'
AND mse.mur_userid = mcs.mur_userid
AND mtx1.textid = mcs.type
AND mtx1.mla_languageid = mse.value
AND mtx2.textid = mcs.state
AND mtx2.mla_languageid = mse.value;

Problem - richtig - mtx1.textid/mtx2.textid ist vom typ INT - also bekomme
ich beim Zugriff auf mcs.type nur den Index, und nicht den "Inhalt". Das
ist nun ziemlich doof. Ich koennte das wahrscheinlich auch irgendwie
dekodieren, aber dazu habe ich ja eigentlich die ENUMs.... Ich bin jetzt
den Umweg ueber eine Mappingtabelle gegangen in der ich die ENUM-Werte in
die dazugehoerige Text-ID umwandle - was besseres ist mir irgendwie nicht
eingefallen. Hat irgendwer eine bessere Idee als:

SELECT mcs.mur_userid
,mcs.capitalsourceid
,mcs.type
,mtx1.text typecomment
,mcs.state
,mtx2.text statecomment
,mcs.accountnumber
,mcs.bankcode
,mcs.comment
,mcs.validtil
,mcs.validfrom
FROM capitalsources mcs
,text mtx1
,text mtx2
,enumvalues mev1
,enumvalues mev2
,settings mse
WHERE mse.name = 'displayed_language'
AND mse.mur_userid = mcs.mur_userid
AND mev1.enumvalue = mcs.type
AND mev2.enumvalue = mcs.state
AND mtx1.textid = mev1.mtx_textid
AND mtx1.mla_languageid = mse.value
AND mtx2.textid = mev2.mtx_textid
AND mtx2.mla_languageid = mse.value;

Wenn Tabellenstrukturen o.ae. benoetigt werden kann ich die liefern...

--
Oliver Lehmann
http://www.pofo.de/
http://wishlist.ans-netz.de/

Re: nummerische ENUM Values

am 26.07.2007 19:43:15 von Kai Ruhnau

Oliver Lehmann wrote:
> ich verwende MySQL 5.0 - leider gibts dort keine Check-Constraints.
> Ich habe das Problem, das ich Datensaetze klassifizieren moecht nach 2
> Kriterien "state" und "type". Der Endanwender soll die Klassifizierungs-
> merkmale in der von Ihm konfigurierten Sprache sehen. Also habe ich mir
> gedacht - erlaube ich als ENUM werte nur die jeweiligen TEXTIDs unter
> denen dann die Uebersetzung gepflegt wird. Z.B.

Ich hab' den Rest mal verworfen, da das nur Folgeprobleme sind:

Warum machst du keine Zwischentabelle mit zwei Zeilen, die die möglichen
(zwei) Klassifikationen und die zugehörige TEXTID enthält? Dazu kannst
du dann normale FOREIGN KEYs anlegen.

Man sollte bei der Benutzung von ENUM nicht vergessen, dass es in
gewissem Sinne eine Denormalisierung ist. In deinem Fall bist du mit
einem normalisierten Design direkt problemlos.

Grüße
Kai

--
This signature is left as an exercise for the reader.

Re: nummerische ENUM Values

am 26.07.2007 20:05:25 von Oliver Lehmann

Kai Ruhnau wrote:

> Warum machst du keine Zwischentabelle mit zwei Zeilen, die die möglichen
> (zwei) Klassifikationen und die zugehörige TEXTID enthält? Dazu kannst
> du dann normale FOREIGN KEYs anlegen.

Hm - das mach ich ja jetzt wie ich schrieb:

# Ich bin jetzt
# den Umweg ueber eine Mappingtabelle gegangen in der ich die ENUM-Werte in
# die dazugehoerige Text-ID umwandle - was besseres ist mir irgendwie nicht
# eingefallen. Hat irgendwer eine bessere Idee als:


> Man sollte bei der Benutzung von ENUM nicht vergessen, dass es in
> gewissem Sinne eine Denormalisierung ist. In deinem Fall bist du mit
> einem normalisierten Design direkt problemlos.

Naja, nicht wirklich, ich habe ein Feld das den Typ des Datensatzes
beschreibt. Ich will halt nur keine wilde Typifizierung erlauben, sondern
nur 2 valide Typen. Normalerweise wuerde ich das mit einem
Check-Constraint sicherstellen - da dies MySQL nicht kann bleibt mir hier
nur ein ENUM wenn ich keine Trigger missbrauchen will (wovon ich noch
weniger halte). Sobald MySQL mal in der Lage ist Check Constraints zu
behandeln fliegen die ENUMs weg.

Eigentlich ist meine "Mappingtabelle" eine Tabelle welche die
Auspraegungen der beiden Domains "Typ" und "Status" beschreibt. Von daher
eigentlich gar nicht so dumm. - Faellt mir gerade ein. Ich bau mir wohl
auch besser eine Funktion welche ich den Namen der Domaine uebergebe (Typ
oder Status) und die Auspraegung der Domaine. Die Funktion liefert mir
dann die passende Bedeutung dieser Auspraegung zurueck... gefaellt mir
ganz gut da kann ich sogar auf meine View verzichten - ok, aber so
langsam drifte ich ab ;)

--
Oliver Lehmann
http://www.pofo.de/
http://wishlist.ans-netz.de/