Wie sollte ich ein Feld modellieren, das in SQL Server 2005 sowohl numerische als auch String-Werte enthalten kann?

Question

Ich habe eine neue Datenbanktabelle, die ich erstellen muss...
Sie enthält logischerweise eine ID , a name und eine "value" .
Dieses Wertfeld kann entweder numerisch oder eine Zeichenkette sein.

Ich glaube nicht, dass ich das Feld einfach zu einem varchar denn ich möchte auch Abfragen mit Filtern durchführen können wie WHERE value > 0.5 und so weiter.

Wie lässt sich dieses Konzept in SQL Server 2005 am besten modellieren?

EDIT: Ich bin nicht dagegen, hier mehrere Felder zu erstellen (eines für Zahlen, eines für Nicht-Zahlen), aber da es sich um dasselbe Konzept handelt, war ich mir nicht sicher, ob das eine gute Idee ist.
Ich schätze, ich könnte separate Felder erstellen und dann eine Ansicht haben, die sie zu einer einzigen logischen Spalte zusammenfasst.

Haben Sie dazu eine Meinung?

Was ich erreichen möchte, ist eigentlich ziemlich einfach... normalerweise werden diese Daten einfach blind in einer rasterartigen Ansicht angezeigt.
Ich möchte auch in der Lage sein, nach den numerischen Werten in dieser Tabelle zu filtern. Diese Tabelle wird am Ende in den zig Millionen von Datensätzen, so dass ich nicht wollen, malen mich in eine Ecke mit Abfrageleistung.
Die Abfrageleistung ist meine Hauptsorge.

Answer 1

Wenn Sie möchten, dass es in der Lage sein, eine Zeichenkette zu halten, ich denke, Sie müssen die Spalte varchar, oder ähnlich zu machen.

Eine Alternative könnte darin bestehen, statt der einen Wertespalte 2 oder 3 Spalten zu haben. Vielleicht haben die drei Spalten value_type (enum zwischen "number" und "string"), number_value, string_value. Dann könnte man die Abfrage wie folgt rekonstruieren

WHERE value_type = 'number' AND number_value > 0.5

Answer 2

Ich glaube nicht, dass Sie in der Lage sein werden, um mit VARCHAR oder NVARCHAR als Datentyp zu umgehen. Bei gemischten Daten, wie Sie sie beschreiben, müssen Sie den Wert testen, wenn Sie das Feld aus der Datenbank herausziehen und das entsprechende CAST oder CONVERT auf der Grundlage des Datentyps durchführen.

Answer 3

Ich schätze, ich könnte separate Felder erstellen und dann eine Ansicht haben, die sie zu einer einzigen logischen Spalte zusammenfasst. Irgendwelche Meinungen dazu?

Das hängt von der Quelle der Daten ab. Wenn Sie die Daten von den Benutzern (oder einem anderen System) in freier Form erhalten und es Ihnen egal ist, um welche Art von Daten es sich handelt, dann ist die beste Art, sie zu speichern, die allgemeinste (varchar usw.). Wenn die eingehenden Daten stärker strukturiert sind und Ihnen diese Struktur wichtig ist, ist es sinnvoller, diese Struktur in der Datenbank zu erhalten, indem Sie separate Felder verwenden.

Aus der Sicht eines SELECT spielt es keine Rolle; Sie können es auf beide Arten speichern und als das gleiche Schema lesen. Sobald Sie sich mit Filtern befassen (wie Sie erwähnen), werden die Dinge etwas haariger, aber immer noch leicht machbar. Sie erwähnen jedoch nicht, ob Sie in der Lage sein müssen, diese Daten zu aktualisieren, und wenn ja, ob Sie eine Validierung der Daten erzwingen müssen.

So wie es sich anhört, müssen Sie je nach "Typ" des gespeicherten Werts verschiedene Arten von Suchen durchführen. Daher kann es sinnvoll sein, ein Feld "Typ" hinzuzufügen, damit alle Filter schnell auf die Art von Werten beschränkt werden können, die Sie interessieren. Beachten Sie, dass ich mit Typ einen logischeren, anwendungsspezifischen Typ meine, nicht den tatsächlichen Datentyp, der gespeichert wird.

Meine Empfehlung wäre, ein einzelnes Feld mit einer Typspalte zu verwenden, wenn Sie UPDATEs leicht unterstützen müssen, oder mehrere Felder (oder Tabellen, wenn es sich um völlig unterschiedliche Datensätze handelt) zu verwenden, wenn SELECTing und Filterung alles ist, was erforderlich ist.

Answer 4

Sie könnten zwei Spalten verwenden, eine "string" und eine "numeric" (welche Varianten davon auch immer geeignet sind), wobei die "string"-Spalte NOT NULL und die "numeric"-Spalte NULL-Werte zulässt. Wenn Sie einen Wert einfügen, füllen Sie immer die "String"-Spalte, unabhängig vom Typ. Wenn der Wert jedoch numerisch ist, speichern Sie ihn AUCH in der "Numeric"-Spalte. Jetzt haben Sie einen eingebauten Indikator für den Typ (wenn die Spalte "numerisch" gefüllt ist, ist es numerisch, wenn nicht, ist es eine Zeichenkette), können den Wert für die Anzeige immer nur aus der Spalte "Zeichenkette" ziehen und den "numerischen" Wert in Berechnungen oder für die richtige numerische Sortierung/Vergleich nach Bedarf verwenden. Sie könnten jederzeit eine dritte Spalte hinzufügen, die den Wertetyp angibt, aber bei diesem Ansatz ist das nicht mehr nötig. Beachten Sie, dass Sie in Erwägung ziehen könnten, die numerischen und String-Werte mithilfe einer Reihe von INSERT- und UPDATE-Triggern zu verwalten.