Mehrere Datentypen in einer Spalte

[PhilipT]

Hallo zusammen,

ich habe mal eine grundsätzliche Frage:
Ich möchte einen Fragebogen über SQL Server 2005 auswerten. Dazu habe ich u.a. alle Antworten in einer bestimmten Spalte gespeichert. Diese Antworten haben unterschiedliche Datenformate (z.B. Text, Zahlen, Datum...).
Macht es nun Sinn, alle Daten in dieser Form - d.h. in eine Spalte - in den SQL Server zu integrieren? Welchen Datentyp würde ich dann dieser Spalte geben?
Oder würde ich besser, abhängig vom Datentypen, die Werte in unterschiedlichen Spalten speichern?
Ich hoffe mein Problem ist deutlich geworden. Freue mich über alle Hinweise.

Danke und Gruss
Philip

[Andreas Kosch]

Hallo,

normalerweise macht es in einer relationalen Datenbank keinen Sinn, in einer Tabellespalte Werte mit unterschiedlichen Datentypen zu speichern. Wenn es jedoch als Ausnahme dieser Regel tatsächlich einen guten Grund dafür gibt, stehen die beiden folgenden Alternativen zur Verfügung:

• SQL_VARIANT
• XML

Das folgende Beispiel demonstriert den Einsatz von SQL_VARIANT:
[highlight=SQL]
USE tempdb
GO

CREATE TABLE dbo.VariantDemo
(
id INT NOT NULL IDENTITY PRIMARY KEY,
wert SQL_VARIANT NOT NULL
)
GO
INSERT INTO dbo.VariantDemo (wert) VALUES (1)
INSERT INTO dbo.VariantDemo (wert) VALUES ('Test')
INSERT INTO dbo.VariantDemo (wert) VALUES (GETDATE())
GO
SELECT * FROM dbo.VariantDemo
[/highlight]

[Jostein]

Hallo,

ich sehe doch einige Anwendungen, in denen es sinnvoll ist, in einer Spalte
unterschiedliche Typen zu speichern, z.B. in mandantenfähigen System, die
je Mandant unterschiedliche Felder haben und alles in einer Tabelle speichern.
Eine solche Tabelle könnte aus den folgenden Spalten bestehen:

Create table FormularWerte 
(
 id      INT Not Null Identity Primary Key,
 FormularId    INT,
 AttributName String,
 AttributValue String
);

Wenn man nun in die Tabelle schreiben will gibt es zwei Ansätze, generisch
oder der Wissensbasierte.
Wissensbasiert heißt, deine Anwendung kann anhand von dem AttributNamen
eine Methode zur transformation auswählen (String nach Integer oder String nach Float).
Für den generischen Ansatz erweiterst du die String, der in der DB gepeichert
wird um ein Zeichen, das den Originaltypen identifiziert (z.B. I=Integer, D=Datum, usw.)
In jedem Fall muß du für jeden Typ zwei Methoden schreiben, für jede Transformationsrichtung eine.

Hilft das weiter ?

Gruß,
Volker

[PhilipT]

Hallo,

erstmal vielen Dank für Eure Hilfe.
Habe SQL_VARIANT als Datentyp ausprobiert- das scheint zu funktionieren. Gibt es irgendwelche Nachteile, wieso man diesen Datentyp nicht einsetzen sollte?
@ Volker: Mit dem Datentyp String bekomme ich die Daten gar nicht komplett integriert - z.B. bei Datumswerten wird mir einfach ein NULL-Wert in die Tabelle geschrieben. Macht es sinn, dass ich nachdem ich die Daten in den SQL-Server integriert habe, die Daten in den entsprechenden Datentyp zu transformieren?

[Bernhard Geyer]

Habe SQL_VARIANT als Datentyp ausprobiert- das scheint zu funktionieren. Gibt es irgendwelche Nachteile, wieso man diesen Datentyp nicht einsetzen sollte?

1, Performance (Variante Datentypen sind immer langsamer als einfache Datentypen)
2, Vendor Lock-In

[Rumtata]

Hi,

hier noch schnell meine Sicht der Dinge:

Den Ansatz von Jostein habe ich bereits in Anwendungen implementiert, bin dabei aber einen Schritt weitergegangen:

Create table FormularWerte 
(
 id      INT Not Null Identity Primary Key,
 FormularId    INT,
 Datentyp int not null,
 DatenInt int null,
 DatenString nvarchar(max) null,
 DatenDateTime DateTime null
 ...
)

In Datentyp steht der Datentyp drin (z.B. 0=int, 1=nvarchar(max) ...) und in den einzelnen Daten...-Feldern die eigentlichen Daten.
Zugegebenermaßen ist das vom Datenbankdesign grottig , aber es ist performant, typsicher, DB-unabhängig und einfachst zu implementieren.

Was Du programm-seitig brauchst, ist halt noch eine Zugriffsschicht, die auf das richtige Feld zugreift...

HTH,
Karsten