Ersatz für GUID als Primärschlüssel

[shmia]

Zitat von generic:

Die Daten werden immer verstreut bzw. dort in die Tabelle geschrieben wo Platz ist.
Einige Datenbank liefern dir nur die Datenmenge immer nach dem Primär Schlüssel sortiert zurück.

Ohne clustered Index schaut eine Datenbank zuerst, ob irgendwo "Löcher" (=gelöschte Datensätze) in der Tabelle sind
und versucht diese zu füllen.
Andernfalls wird am Ende der Tabelle (bzw. der Datenbank) physikalisch angefügt.
Das ist mit anderen Worten das was du geschrieben hast.

Mit clustered Index ist das Verhalten so:
Der clustered Index wird benützt, um die Einfügestelle zu finden.
Ist auf der Seite (8kb) noch Platz für den Datensatz, wird er dort reingeschrieben.
Andernfalls wird die Seite gesplittet.

Um mein Problem zu verstehen muss man verstehen, wie ein clustered Index funktioniert.
Hier wird erklärt, weshalb GUIDs als Primärschlüssel und clustered Index eine schlechte Performance haben:
http://www.insidesql.org/quick-tips/clustered-indexes

Man könnte nun den clustered Index auf ein anderes Feld legen, aber das geht aus folgenden Gründen nicht so einfach:
1.) es ist nicht vorhersehbar, wie lange das Umstellen des clustered Index dauert (kann viele Stunden brauchen)
Die Datenbank ist "mission critical" und wenn die DB auf unbestimmte Zeit down ist, dann gibt das Ärger
2.) viele Kunden setzen die kostenlose Express Edition *) ein. Die Grösse einer DB ist auf 4 GB limitiert.
Löschen und Neuanlegen des clustered Index braucht sehr viel Platz.
Sollte das 4GB Limit erreicht werden, dann ist die Datenbank "kaputt" und kann nur noch mit einem kostenpflichtigen SQL Server Standard Edition gerettet werden.
*) Sie sparen sich 2000-3000 Euro für die Std Edition; das ist Sparen am falschen Platz

[p80286]

Mein Beileid
"wir sparen, koste es was es wolle"

Gruß
K-H

[Blup]

Das Hauptproblem lässt sich auch nicht mit einem "Clustered Index" lösen.
Die 80 Felder sagen eindeutig schlechte Datenbankstruktur.
Wie viele Datensätze passen denn da noch in einen Cluster?

Prüft erst mal, welcher Index bei der Verarbeitung wirklich genutzt wird. Mit optimalem Index macht es normalerweise keinen wesentlichen Unterschied ob 10 oder 10millionen Datensätze in der Tabelle vorhanden sind. Müssen 10 Datensätze verarbeitet werden, sind das im schlimmsten Fall 10, im optimalen Fall 1 Cluster.

Wenn der Bericht jeweils nur die neuen Daten enthalten soll, könnte mit einer zusätzlichen Tabelle gearbeitet werden, die nur die ID der neuen Datensätze enthält und nach Erstellung des Berichts wieder gelöscht wird.

Führt das nicht zu Ziel, muss für diese Daten eine neue Struktur gefunden werden. In der Haupttabelle sollten neben der ID nur Felder bleiben, die für Referenzen auf andere Tabellen benötigt werden (KundeID oder ähnliches) und Felder die indiziert werden (z.B. Datum für Index KundeID + Datum). Alles andere kann z.B. in einer zugehörigen Wertetabelle über ID, Typ, Wert (PK über ID und Typ) abgelegt werden.

Muss die Datenbank fast durchgehend verfügbar sein, kann so eine Umstellung auch schrittweise im laufenden Betrieb erfolgen. Dazu müssen natürlich alle Zugriffe zuerst auf eine "Procedure" oder "View" umgestellt werden, die beide Datenstrukturen auswertet. Neue Daten werden in die neue Struktur geschrieben.
Ein Hintergrundprozess kann dann je nach Auslastung innerhalb einer "Transaction" einige Datensätze aus der alten Struktur in die neue überführen und aus der alten Tabelle entfernt. Cluster die von der alten Tabelle nicht mehr belegt sind, werden dabei automatisch für die neue Struktur verwendet. Die Größe der Datenbank würde sich dadurch nur unwesentlich ändern.