Enums in Sql-Server?

[Walter]

Bin ich blind oder gibt es immer noch keine Enums in Sql-Server? Überseh ich da was?

Postgresql hat sie, Oracle hat sie, Mysql hat sie... Und sie sind wesentlich besser als die Alternativ-Vorschläge

• "mach doch eine eigene Tabelle". Wenn man ein umfangreicheres Datenmodell hat landet man da rasch bei dutzenden sinnlosen Tabellen die zusätzlich die Performance verschlechtetrn
• Gebastel mit CHECK in der Art

  CHECK(yourColumnName IN (‘WERT1’,’WERT2’,’WERT3’,......))

 

[dabadepdu]

Wusste gar nicht, dass es sowas gibt.

So fürchtericrlich finde ich jetzt den alten Check Constraint nicht.
Wenn man eine mehrsprachige Anwendung hat, finde ich beides (Stringliste und Enum Typ) nur begrenzt nutzbar. Dann lieber ordentlich ins Datenmodel einbauen- mit fk.

Tja und solange ich MSSQL nicht beruflich nutzen muss, pack ich da sowieso nichts an.

 

[Walter]

@dabadepdu All dieses Gebastel ersetzt keine Enums. Die Gründe habe ich dargelegt. Und Mehrsprachigkeit ist nun wirklich kein Argument gegen Enums - der Anwender bedient schliesslich ein UI und keine DB.

 

[castorp]

die zusätzlich die Performance verschlechtetrn

Das stimmt schlicht nicht.

Oracle hat sie

Seit wann?

 

[Walter]

Das stimmt schlicht nicht.

Was ist mit den dadurch notwendigen Foreign Key checks?

Seit wann?

Oracle Database 23ai

 

[castorp]

Was ist mit den dadurch notwendigen Foreign Key checks?

Natürlich brauchen FK Prüfungen "Zeit". Nach meiner Erfahrung ist der Einfluss im "normalen Betrieb" aber meistens nicht beobachtbar. Bei bulk loads von zig/hunderten Millionen von Datensätzen kann das unter Umständen ein Problem werden.

Oracle Database 23ai

Ah, die neuen DOMAINs, danke.

 

[Walter]

Einfluss im "normalen Betrieb"

Wenn man grosse Anwendungen hat mit vielen Usern will man sich nicht auch noch hunderte unnötige FK mit zusätzlichem IO aufbinden. Ausserdem werden bei Anwendungen/Auswertungen viele zusätzliche Joins nötig

Und das Hauptargument gegen diese Lösung bleibt, die dutzenden oder hunderten unnötigen Tabellen, die dadurch entstehen und völlig sinnlos sind.

Vor allem, wenn es eine saubere Lösung gibt, die manche Hersteller nur nicht umsetzen.

 

[castorp]

Und das Hauptargument gegen diese Lösung bleibt, die dutzenden oder hunderten unnötigen Tabellen, die dadurch entstehen und völlig sinnlos sind.

Ich empfinde diese Tabellen weder als unnötig noch sinnlos.
Wie gesagt, der Overhead wird - nach meiner Erfahrung - in den allermeisten Fällen nicht spürbar sein.

 

[Walter]

Jetzt wird es kindisch. Ich könnte jetzt auch noch einmal meine Argumente wiederholen, dann wiederholst Du Deine, dann wieder ich meine...

 

[akretschmer]

Jetzt wird es kindisch. Ich könnte jetzt auch noch einmal meine Argumente wiederholen, dann wiederholst Du Deine, dann wieder ich meine...

ich habe schon Installationen mit einigen Millionen Tabellen gesehen, ich sehe es nicht als Problem, eine relationale Datenbank als solche zu nutzen. Dazu gehören dann auch FK-Tabellen etc.

 

[Walter]

ich habe schon Installationen mit einigen Millionen Tabellen gesehen, ich sehe es nicht als Problem, eine relationale Datenbank als solche zu nutzen. Dazu gehören dann auch FK-Tabellen etc.

Und ich habe schon die grösste Oracle-Installation Österreichs unter der Last fast zusammenbrechen sehen weil Entwickler zu wenig an Ressourcenverbrauch dachten.

 

[MDDaniel]

Zur Frage: Du hast es nicht übersehen. MSSQL unterstützt das nativ nicht. Es geht nur mit "Gebastel" z.B. externen Code einbinden.

/Off-Topic
Wobei ich mir noch ein wenig schwer tue, den großen Vorteil von Enums zu sehen wenn sie nur einen einzigen Wert darstellen und diesen nicht maskieren.

 

[akretschmer]

Und ich habe schon die grösste Oracle-Installation Österreichs unter der Last fast zusammenbrechen sehen weil Entwickler zu wenig an Ressourcenverbrauch dachten.

Österreich ... da hat meine jetzige Firma mal 180TB von Oracle nach PG migriert ... und das war nix geringeres als die Nationalbank.
Falls an der Geschichte jemand Interesse hat: PN an mich.

 

[dabadepdu]

der Anwender bedient schliesslich ein UI und keine DB

Dann wird halt im Code der UI gebastelt, falls die Enum Werte noch übersetzt werden müssen.*

Ich kann die Performanceproblematik und das Komplexitätsproblem schon verstehen. Aber ob man sich mit Enums den A.. retten kann, ob also viele Nachschlagetabellen diese Problematik verursachen, wage ich zu bezweifeln. Da z.B. die Frage, wie denn die Enums auf der DB implementiert sind. (Sinnlos, wenn sie nicht implementiert sind) Wenn es gut gemacht ist, wahrscheinlich mit einer versteckten, normalisierten Tabelle und FK.
Erfahrungsgemäß ist z.B. in komplexen, großen DB das Löschen ein Problem, außer es wurde dafür eifrig eine Optimierung gepflegt.
Meine andere Erfahrung ist, dass konkurrierende Zugriffe (viele Benutzer) in MSSQL grundsätzlich ein Problem sind, Lock Escalation, ... Ist zum Glück schon was her, ist bestimmt besser geworden.

da hat meine jetzige Firma mal 180TB von Oracle nach PG migriert .

Größe ist nicht unbedingt gleichbedeutend mit Komplexität, wahrscheinlich bei Banken auch eher weniger.

@Walter
Wenn Du Dir sicher bist, dass separate Hilfstabellen oder der alte, String basierte Check Constraint zu viel Ressourcen kosten (was ich grundsätzlich nicht vermuten würde),
und eh (immer) die UI dazwischen hängt (App Server, REST API oder so)
und es vielleicht gar kein heterogenes System ist
und auch keine Spezis zu Fuß in der DB rumwurschteln,
dann trag nur Rohwerte ein und prüfe die zyklisch auf Gültigkeit in einer Phase, wo wenig Last auf der DB ist.
Es wäre am Ende eine Frage von Mutwillen, Doofheit oder Programmfehlern, wenn falsche Werte reinkommen. (Ja, ich weiß, dass es das trotzdem gibt)
Komplexe Inserts oder Updates zu verbieten (Grant) und durch smarte SP zu ersetzen, kann da auch Vorteile bringen.

* Das ist natürlich auch eine zulässige Strategie, um Last von der DB zu nehmen. Zumindest, wenn es gut umgesetzt ist. MS macht es ja sogar mit seinem .NET offline Verfahren ziemlich krass, wenn FAT Clients nur zum Lesen und Schreiben verbinden und keine durchgehenden Sessions haben. Ich weiß ehrlich gesagt gar nicht, ob das im Zeitalter von tonnenweise RAM auf dem DB Server noch so praktiziert / propagiert wird von denen.

 

[t-sql]

Gerade mal geschaut. Enums sind kein Standarddatentyp von SQL. Damit isses proprietär und nicht zu gebrauchen.