Ich habe eine Anfrage, dass eine dynamische Tabelle 1000 Spalten haben soll (zufällig von meinen Endbenutzern ausgewählt). Das scheint mir eine schlechte Idee zu sein. Es ist eine anpassbare Tabelle, so dass es eine Mischung aus varchar(200) und float Spalten hat (float passt am besten zu den Anwendungen c ++ double type). Diese Datenbank ist meist ein Index für eine Legacy-Anwendung und dient als Berichts-Repository. Es ist nicht das System der Aufzeichnung. Die Anwendung hat tausende von Datenpunkten, von denen sehr wenige normalisiert werden könnten.
Irgendwelche Ideen, was die Auswirkungen auf die Leistung sind? Oder eine ideale Tabellengröße, um dies auch zu partitionieren?
Da ich nicht weiß, welche Felder von 20k Auswahlmöglichkeiten die Endanwender wählen werden, ist es nicht machbar, die Tabellen zu normalisieren. Ich kann diese Daten zu mehreren Tabellen trennen, die ich dynamisch verwalten müsste (Felder können hinzugefügt werden oder fallen gelassen werden. Die Reihen werden dann gelöscht und das System des Datensatzes wird geparst, um die Tabelle zu füllen.) Meine Präferenz ist zurück zu schieben und Normalisieren Sie alle 20 KB Daten. Aber ich sehe das nicht.
Das riecht für mich nach einem schlechten Design.
Dinge zu beachten:
Werden die meisten dieser Spalten NULL-Werte enthalten?
Werden viele als Property001, Property002, Property003, etc ... bezeichnet?
Wenn dem so ist, empfehle ich Ihnen, Ihre Datennormalisierung zu überdenken.
aus SQL2005-Dokumentation:
SQL Server 2005 kann bis zu zwei Milliarden Tabellen pro Datenbank und 1.024 Spalten pro Tabelle enthalten. (...) Die maximale Anzahl an Bytes pro Zeile beträgt 8.060. Diese Einschränkung wird für Tabellen mit Spalten varchar, nvarchar, varbinary oder sql_variant gelockert, die dazu führen, dass die gesamte definierte Tabellenbreite 8.060 Byte überschreitet. Die Länge jeder dieser Spalten muss immer noch innerhalb der Grenze von 8.000 Bytes liegen, aber ihre kombinierten Breiten können die Grenze von 8.060 Byte in einer Tabelle überschreiten.
Was ist die Funktionalität dieser Spalten? Warum nicht besser in Haupttabelle, Eigenschaften (Nachschlagetabellen) und Werte aufteilen?
Wann immer Sie das Bedürfnis haben zu fragen, welche Grenzen das System hat, haben Sie ein Designproblem.
Wenn Sie gefragt haben "Wie viele Zeichen kann ich in ein Varchar einfügen?" dann solltest du überhaupt keine Varchare verwenden.
Wenn Sie wirklich wissen wollen, ob 1000 Spalten in Ordnung sind, müssen Sie die Daten unbedingt reorganisieren. (Normalisierung)
MS SQL Server hat ein Limit von 1024 Spalten pro Tabelle, also werden Sie direkt am Rand davon laufen. Wenn Sie varchar (200) -Spalten verwenden, können Sie die Grenze von 8 KB pro Zeile überschreiten, da SQL 8 KB auf der Datenseite speichert und dann die Daten außerhalb der Seite überläuft.
SQL 2008 hat Sparse Columns für solche Szenarien hinzugefügt - in denen Sie viele Spalten mit Nullwerten haben würden.
Sparse-Spalten verwenden Ссылка
In der Regel gilt: je breiter die Tabelle, desto langsamer die Performance. Viele dünne Tische sind einem dicken Durcheinander eines Tisches vorzuziehen.
Wenn Ihr Tisch so breit ist, ist es fast sicher ein Designproblem. Es gibt keine wirkliche Regel, wie viele vorzuziehen sind. Ich habe nie wirklich Tische mit mehr als 20 Spalten in der realen Welt gefunden. Einfach nach Beziehung gruppieren. Es ist schließlich ein RDBMS.
Dies wird enorme Leistungs- und Datenprobleme verursachen. Es muss wahrscheinlich normalisiert werden.
Während der SQL-Server eine Tabelle erstellen kann, die mehr als 8060 Bytes in der Zeile enthält, können Sie NICHT mehr Daten als die darin speichern. Sie könnten Daten unerwartet abgeschnitten haben (und schlimmer nicht, bis einige Monate später dies passieren könnte, und zu diesem Zeitpunkt ist die Behebung dieser Monstrosität sowohl dringend als auch extrem hart).
Das Abfragen wird auch ein echtes Problem sein. Woher weißt du, welche der 1000 Spalten nach den Daten suchen? Sollte jede Abfrage nach allen 1000 Spalten in der Where-Klausel fragen?
Und die Vorstellung, dass dies benutzerdefinierbar wäre, ist in der Tat beängstigend. Warum benötigt der Benutzer 1000 Felder zum Anpassen? Die meisten Anwendungen, die ich gesehen habe, die dem Benutzer die Möglichkeit geben, einige Felder anzupassen, setzen ein kleines Limit (normalerweise weniger als 10). Wenn sie so viel anpassen müssen, hat die Anwendung keine gute Arbeit geleistet, um zu definieren, was der Kunde tatsächlich benötigt.
Manchmal muss man als Entwickler nur aufstehen und nein sagen, das ist eine schlechte Idee. Dies ist eine dieser Zeiten.
Was Sie stattdessen tun sollten (außer Normalisieren), ich denke, wir würden mehr Informationen brauchen, um Sie in die richtige Richtung zu weisen.
Und BTW, float ist ein ungenauer Datentyp und sollte nicht für Felder verwendet werden, in denen Berechnungen stattfinden, es sei denn, Sie mögen falsche Ergebnisse.
Ich muss hier allen widersprechen ..... Ich weiß, dass es verrückt klingt, aber Tische mit Hunderten von Spalten zu verwenden, ist das Beste, was ich je gemacht habe.
Ja, viele Spalten haben häufig Nullwerte. Ja, ich könnte es auf ein paar Tabellen normalisieren und transponieren; Ja, es ist ineffizient
Es ist jedoch unglaublich schnell und einfach, Spaltendaten auf unendlich viele verschiedene Arten zu analysieren
Verschwenderisch und unelegant - Sie werden niemals etwas so Nützliches bauen!
Das ist zu viel. Mehr als 50 Spalten breit und Sie benötigen Probleme bei der Leistung, der Codewartung und der Fehlerbehebung bei Problemen.
Scheint sehr viel. Ich würde zuerst sicherstellen, dass die Daten normalisiert sind. Das könnte Teil deines Problems sein. Welchen Zweck erfüllen diese Daten? Ist es für Berichte? Werden sich die Daten ändern?
Ich würde denken, dass ein Tisch, der weit ist, eine alptraumhafte Leistung und Wartungs-weise sein würde.
Haben Sie daran gedacht, Ihre letzte Tabelle (1000 Spalten) als Ergebnis einer Kreuztabellenabfrage anzuzeigen? Ihre ursprüngliche Tabelle hätte dann nur ein paar Spalten, aber viele tausend Datensätze.
Können Sie Ihr Problem näher erläutern? Ich glaube niemand versteht wirklich warum du diese 1000 Säulen brauchst!
Tags und Links sql-server sql-server-2005