Ich habe einige Daten, welche Spalten dynamisch sind und die Anzahl der Spaltendaten kann jederzeit erhöht / verringert werden. Daher plane ich, sie reihenweise anstelle des Spaltenformats zu speichern.
Ich habe die Haupttabelle der Spalten platziert und es zeigt an, welchen Datentyp die Spalten verwenden. Ich zeichne die Master-Tabelle unten für Ihre Referenz
%Vor%Jetzt habe ich über zwei Möglichkeiten nachgedacht, um diese dynamischen Spaltendaten zu speichern Der erste Weg ist
%Vor%Der zweite Weg war, eine verallgemeinerte varchar-Spalte zu haben und jeden Wert als String dort zu speichern, so dass er aussieht wie
%Vor%Wenn Sie den Gesichtspunkt der Normalisierung der Datenbank betrachten, dann scheint der zweite Weg gut zu sein. Aber ich denke, dass es beim Datenabruf Probleme verursachen kann. Weil ich die Daten wie "Geschwindigkeit & gt; 10" filtern möchte. Also, wenn ich den zweiten Weg gehe (wo ich alle Werte als String speichern werde), denke ich, dass der Ausdruck mehr Zeit braucht um zu evaluieren Und wenn ich zuerst für den Ausdruck gehe, dann muss ich zuerst die Spalten bestimmen, gegen die ich den Ausdruck evaluieren muss. Ex. für den Ausdruck Geschwindigkeit & gt; 10, zuerst muss ich überprüfen, Geschwindigkeit ist von welcher Datentyp (string, bool etc) und dann wieder den Ausdruck von "data_double & gt; 10"
Beide haben ihre eigenen Nachteile. Kann jemand darauf hinweisen, welcher Weg mir in Zukunft weniger Kopfschmerzen bereiten wird? Denken Sie daran, dass diese Tabelle in späteren Phasen in Millionen von Datensätzen wachsen wird.
Ich schätze Ihre Meinung und Zeit hier. Danke.
Ich bin mir nicht sicher, wie Sie auf die Daten zugreifen, vielleicht SQL_Variant kann eine Option für Sie in Kombination mit SQL_VARIANT_PROPERTY sein.
%Vor%Ein Ansatz könnte darin bestehen, für jeden Datentyp, an dem Sie interessiert sind, eine einzige Tabelle zu verwenden. Jede dieser Tabellen hätte nur zwei Felder. Ein Int-Typ PK und eine entsprechende Spalte zum Speichern von Daten. In der Master-Tabelle könnten Sie einfach einen FK vom int-Typ haben, der mit einer der spezifischen Typ-Tabellen verknüpft ist, und ein anderes Feld vom tinyint-Typ, das entscheidet, zu welcher untergeordneten Tabelle der FK gehört.
Master-Tabelle
ID int PK
ValueID int Nicht Null
Geben Sie tinyint Not Null
einuntergeordnete Tabelle (n)
ID int PK
Wert Zeichenfolge Nicht Null
Die ValueID ist FK von der Child-Tabelle zur Master-Tabelle. Ähnliche untergeordnete Tabellen können für andere Typen erstellt werden.
Ich weiß, dass dies Ihre Frage, welche dieser beiden Optionen besser ist, nicht beantwortet, aber ich hoffe, dass es trotzdem nützlich sein wird.
Ich würde mit keiner dieser beiden Optionen gehen. Ich würde lieber versuchen zu sehen, ob ich diese in Spalten (es ist nicht ungewöhnlich, Tabellen mit 50 oder 100 und noch mehr Spalten) und / oder verschiedene Tabellen passen.
Ich würde empfehlen, TFS oder Dynamics CRM zu installieren und zu sehen, wie sie Daten speichern. Sie haben den Anwendungscode so erstellt, dass er Spalten in der Datenbank hinzufügen / löschen kann, und sie haben eine Reihe von Tabellen, die diese Metadaten verfolgen.
Wenn es wirklich so viele verschiedene Werte gibt, würde ich es mit XML-Datentypen versuchen.
Ich habe diese Art von Problemen mehrfach gesehen und mit ihnen gearbeitet, insbesondere dort, wo die Anwendung die Benutzerkonfiguration von Feldnamen und Datentypen zulassen muss.
Die Lösung in diesen Fällen waren Schlüsselwerttabellen (dh zweispaltig), die varchars für alle Schlüssel [offensichtlich] aber auch für alle Werte verwendeten.
Dies ist eine sehr leistungsfähige Lösung, die ihre Einfachheit täuscht!
Obwohl dies die einfachste und erweiterbarste Option ist, ist sie möglicherweise nicht die leistungsfähigste. Eine Key-Value-Tabelle für jeden Datentyp zu haben, kann helfen, ist aber etwas schwieriger zu programmieren. Alternativ können Sie auch ein Type-Feld und Spalten für jeden Datentyp in derselben Tabelle einfügen (ist aber nicht mein Favorit, da dadurch Platz verschwendet wird).
Die datenbankbasierten Anwendungen, an denen ich gearbeitet habe und die den varchar-Value-Ansatz verwendet haben, wurden ohne merkliche Langsamkeit ausgeführt. Sie operierten jedoch nur mit einfachen key-basierten Lookups. Ihre Situation kann abweichen, insbesondere wenn Sie komplexere Abfragen zu Ihren Daten durchführen. Das Offenlegen der offensichtlichen, aber das Anwenden von Primärschlüsseln auf die Schlüsselfelder verbessert die Suchgeschwindigkeit.
Zusätzliche Hinweise:
Ich bitte um Entschuldigung dafür, dass ich das, was ich in verschiedenen Foren gelesen habe, wiederverwertet habe, aber ich habe in meinen eigenen Datenbanken keine Variantentypen verwendet. Ich habe gelesen:
1) In SQL Server 2005 führt die Verwendung eines Variantentyps anstelle eines Varchartyps - in diesem Fall für die Spalte "Wert" - zu einer schnelleren Ausführung,
2) sie funktionieren nicht mit LIKE in WHERE-Klauseln,
3) OLE DB- und ODBC-Provider konvertieren Varianten automatisch in nvarchar (4000).
Tags und Links sql sql-server c# sql-server-2008