MSSQL: 3x BIT-Fields (but only one should be set TRUE)

Froschkoenig84

Froschkoenig84

Aktiver Benutzer
Beiträge
27
Ich hab ein Artikel-System und versuche ein ENUM('CONTINENT','COUNTRY','DESTINATION') in TransSQL nachzubauen. Benötigt wird es als Typen-Feld für eine dynamische Foreign-ID-Spalte.

Klar mit VARCHAR IN('CONTINENT','COUNTRY','DESTINATION') geht das auch in MSSQL, aber ich möchte es möglichst klein und einfach halten, da ich bei 250 Mio Datensätzen schnelle Reaktionszeiten benötige.

Zunächst dachte ich an ein TINYINT-FIELD und ich gebe den Werten einfach skriptseitig eine ID, aber ich weiß nicht, ob da später noch weitere Werte dazwischen ergänzt werden sollen und wirklich verständlich ist so ein Feld auch nicht.

Deswegen die drei BIT-Felder: is_continent, is_country, is_destination, ... was sich später auch durch weitere Felder wie is_state, is_region, is_region, ... erweitern ließe.

Generell erscheit mir diese Lösung als simpel, allerdings würde ich gerne - um spätere Fehl-INSERTs/-UPDATEs zu vermeiden - eine Regel erstellen, so dass nur immer eines dieser Felder TRUE sein darf. (auch schön, aber rein optional wäre ein TRIGGER mit BEFORE-UPDATE SET ... = FALSE)

Das geht sicherlich auch in MSSQL, irgendwas mit ADD CONSTRAINT und dann ein CHECK() oder so. Ich bin nicht so fit auf MSSQL, jemand eine Idee, wie ich solch eine Regel integrieren kann?

Falls jemand eine bessere Idee hat, dann raus damit!! :)
 
Werbung:
Du hast eigentlich alle wesentlichen Suchbegriffe genannt...
Code: 
ALTER TABLE tabelle ADD CONSTRAINT constraint_name
CHECK (cast(isnull(is_continent,0) AS SMALLINT)+isnull(is_country,0)+isnull(is_destination,0)=1)
 
Mein MSSQL hat gemeckert wenn ich versucht habe 3 BITs zu addieren denn es bleibt vom Typ her ein BIT und das kann man nicht addieren. Wenn ich aber den ersten Wert zum INT caste macht er beim zweiten auch autoatisch INT (kann man natürlich auch explizit schreiben) und addiert alles auf.
 
Werbung:
Die bessere Lösung, die auch besser skaliert, wäre übrigens eine Nachschlagetabelle (mit primary key, und in der Zieltabelle ein Foreign Key). Dann können auch weitere Felder bzw. Werte dazukommen, ohne daß Du Dein Tabellendesign ändern müßt. So ist das nur, sorry, Müll.
 
Zurück
Oben