Ist es in SQL Server möglich, den Typ eines Felds basierend auf dem Inhalt eines anderen Felds zu konvertieren?

Question

Ich habe eine Tabelle, DD, die ein Datenwörterbuch ist, mit Feldern (sagen wir):

ColumnID (longint PK), ColumnName (varchar), Datatype (varchar) 

Ich habe eine weitere Tabelle, V, wo ich Sätze von Datensätzen in der Form haben:

ColumnID (longint FK), ColumnValue (varchar) 

ich möchte in der Lage sein, Gruppen von Datensätzen von V in eine andere Tabelle zu konvertieren, Ergebnisse, wobei jedes Feld wird auf der Grundlage der Wert von DD.Datatype übersetzt werden, so dass die Zieltabelle (sagen wir) sein könnte:

ColumnID (longint FK), ColumnValue (datetime) 

Um in der Lage zu sein, dies zu tun, ISTM, die ich brauche

CONVERT(value of DD.Datatype, V.ColumnValue) 

wie

etwas in der Lage sein zu tun

Kann jemand mir irgendwelche Hinweise darauf, ob dies überhaupt möglich, und wenn ja, was die Syntax wäre? Mein Google-Fu hat sich als unzureichend erwiesen, um irgendetwas relevantes zu finden

Answer 1

Sie könnten so etwas mit dynamischen SQL, sicherlich tun. Solange Sie sich der Einschränkung bewusst sind, dass der Datentyp eine Eigenschaft der Spalte in der Ergebnismenge ist und nicht jede Zelle in der Ergebnismenge. Daher müssen alle Zeilen in einer bestimmten Spalte den gleichen Datentyp haben.

Answer 2

Der einzige Weg, um etwas wie CONVERT(value of DD.Datatype, V.ColumnValue) in SQL zu erreichen, ist mit dynamischem SQL. Das hat seine eigenen Probleme, wie etwa die Notwendigkeit, gespeicherte Prozeduren zu verwenden, um Abfragen effizient zu halten.

Alternativ könnten Sie die Metadaten des Datentyps mit einer Abfrage abrufen, eine neue Abfrage in Ihrer Anwendung erstellen und anschließend die Datenbank erneut abfragen. Vorausgesetzt, dass Sie SQL Server verwenden 2012+, könnten Sie auch versuchen, TRY_CAST() oder TRY_CONVERT() verwenden, und das Schreiben der Abfrage wie:

SELECT TRY_CAST(value as VARCHAR(2)) FieldName 
FROM table 
WHERE datatype = 'VARCHAR' AND datalength = 2 

Aber noch einmal, Sie haben wissen, was die gültigen Typen sind; Sie können das nicht dynamisch mit SQL ohne dynamisches SQL ermitteln. Variablen und Parameter dürfen nicht für Objekt- oder Typnamen verwendet werden. Unabhängig davon, was Sie tun, müssen Sie jedoch daran denken, dass alle Daten in einer bestimmten Spalte einer Ergebnismenge den gleichen Datentyp haben müssen.

Most Entity-Attribute-Value tables wie diese Opfer Datenintegrität, die starke Typisierung bringt durch die Annahme, dass der Datentyp von der Anwendung und nicht das RDBMS bestimmt wird. EAV erlaubt dir nicht, deinen Kuchen zu haben (Daten ohne ein festes Schema zu speichern) und es auch zu essen (genießt, dass DB starke Datentypen erzwingt, keine Zeichenketten in der Anwendung schreiben, etc.).

EAV bricht Daten Normalisierung ziemlich schlecht. Es bricht die erste Normalform; die grundlegendste Regel, und das ist nur eine der Konsequenzen. EAV-Tabellen werden das Abfragen der Daten von schwierig bis extrem schwierig machen, und Sie werden fast immer die Leistung opfern, weil das RDBMS auf dem relationalen Modell basiert.

Das bedeutet nicht, dass Sie nie EAV-Tabellen verwenden sollten. Sie sind relativ groß für benutzerdefinierte Felder. Es bedeutet jedoch, dass sie immer zu saugen, um zu fragen und zu verwalten sind. Das ist nur der Kompromiss. Du hast die erste Normalform gebrochen. Abfrage und Leistung werden Konsequenzen dieser Wahl haben.

Wenn Sie Ihre alle Ihre Daten so speichern möchten, sollten Sie entweder Daten als Blobs von XML oder JSON (SQL Server 2016) speichern - aber das ist ein allgemeiner Schmerz zu Abfrage - oder verwenden ein NoSQL-Datenspeicher wie MongoDB oder Cassandra anstelle eines SQL-RDBMS.