SQL Select Spaltenname dynamisch

[WernerK]

Hallo

In einer SQL Server Tabelle DOCUMENTS gibt es die Spalten German und English. Eine Webanwendung macht einen Select auf diese Tabelle aber abhängig von der gewählten Sprache des Anwenders. Wenn er nun z.b. auf Spanisch eingestellt hat, kommt eine SQL Fehlermeldung "Invalid column name 'spain'"

Könnte man vielleicht den Spaltennamen so wählen, dass wenn eine andere Sprache als German oder English gewählt wurde, immer English genommen wird im Select? Ich habe dazu ein SQL Snippet gefunden wie man die Spalten prüfen könnte.

Im Beispiel unten würde auf "spain" geprüft. Das gibt es aber nicht und dann soll der Select mit English gemacht werden. Leider geht das mit dem IF und ELSE und den Selects dazwischen so nicht.

Wie könnte man das erreichen?

IF EXISTS (SELECT * FROM Information_Schema.Columns WHERE Table_Name = 'DOCUMENTS' AND Column_Name = 'spain')
PRINT 'Spalte <SpaltenName> existiert in Tabelle ';
SELECT spain,  [ID] FROM [DOCUMENTS]
ELSE
PRINT 'Spalte existiert nicht';
SELECT ENGLISH,  [ID] FROM [DOCUMENTS]

Gruss

Werner

[Pit]

Hallo

In einer SQL Server Tabelle DOCUMENTS gibt es die Spalten German und English. Eine Webanwendung macht einen Select auf diese Tabelle aber abhängig von der gewählten Sprache des Anwenders. Wenn er nun z.b. auf Spanisch eingestellt hat, kommt eine SQL Fehlermeldung "Invalid column name 'spain'"

Hallo,

warum versuchst du das SQL-seitig zu beheben?

Wenn Deine Webanwendung ohnehin hier differenziert, wäre es doch einfach, die Fehlerbehandlung an dieser Stelle vorzunehmen.

Pit

[dedlfix]

Tach!

Leider geht das mit dem IF und ELSE und den Selects dazwischen so nicht.

"Geht so nicht" geht so nicht als Fehlerbeschreibung. Es darf schon etwas genauer sein, damit man weiß, woran es scheitert und wo/ob man da ansetzen kann.

Wie könnte man das erreichen?

Das Problem ist, dass man keine Query erstellen kann, die auf nicht vorhandene Felder zugreift. Die Syntax wird anscheinend nicht erst zur Laufzeit ausgewertet, so dass ein nicht vorhandenes Feld einen Fehler darstellt. Daraus folgt, dass man solche Syntax erst zur Laufzeit erzeugen darf. Und es sieht aus, als ob EXECUTE das leisten kann.

Andererseits ist das Tabellendesign fragwürdig, wenn mehr als die zwei Sprachen vorkommen können, und du das außerdem nicht in der Clientanwendung abfängst. Gleichartige Daten lassen sich besser untereinander in Zeilen statt nebeneinander in Spalten verwalten. Wenn es zu einem Datensatz etwas in mehreren Sprachen gibt, ist das eine 1:n-Beziehung, und das sollte man auch so modellieren.

dedlfix.

[WernerK]

Hallo dedlfix,

mir gefällt das DB Design auch nicht so recht. Der Gedanke war wohl ursprünglich, dass der Anwender den Inhalt in einem Select in seiner Sprache sieht.

Beispiel:

Id, German, English
RED, Rot,   Red

BLUE, Blau, Blue

Wie willst du das aber untereinander darstellen?

Gruss

Werner

[dedlfix]

Tach!

Der Gedanke war wohl ursprünglich, dass der Anwender den Inhalt in einem Select in seiner Sprache sieht.

Kann man so machen. Aber das was auf der Benutzeroberfläche angezeigt wird muss nicht 1:1 dem Datenbankdesign entsprechen.

Wie willst du das aber untereinander darstellen?

Ich sprach nicht von der Darstellung sondern von der Modellierung des Datenmodells. Wenn das UI besser nebeneinander aufgebaut werden soll, dann mach das so. Der Code im Hintergrund kann dazu auch etwas komplexer ausfallen als: Datensatz holen, Formularzeile erstellen. Beispielsweise Zeile aus der Haupttabelle holen, dazugehörige Sprachen holen Formularzeile anfangen, Feld je Sprache anhängen. Das Beispiel ist nicht besonders toll, weil zu jeden Datensatz eine weitere DB-Abfrage abgeschickt wird. Das lässt sich aber auch umstellen auf zum Beispiel: alle (für die aktuelle Seite relevanten) Sprachdaten holen, zwischenlagern und beim Formularzeile-Erstellen auf den Zwischenspeicher zugreifen.

dedlfix.