Datenbankentwurf und -leistung (SQL Server Compact)

  • Artikel

Sie können die Leistung der Anwendung von SQL Server Compact 3.5 (SQL Server Compact 3.5) erheblich verbessern, indem Sie die Datenbank und Veröffentlichung von SQL Server ordnungsgemäß entwerfen. In den folgenden Abschnitten werden Techniken beschrieben, die Sie zum Verbessern der Leistung verwenden können.

Datenbankdenormalisierung verwenden

Normalisierte Datenbanken verhindern funktionale Abhängigkeiten in den Daten, wodurch das Aktualisieren von Datenbanken einfach und effizient wird. Allerdings erfordert das Abfragen der Datenbank möglicherweise viele Verknüpfungen von Tabellen, um Informationen zu kombinieren. Mit der Zunahme von Verknüpfungstabellen erhöht sich die Abfrageausführungszeit erheblich. Daher ist eine normalisierte Datenbank nicht immer die beste Wahl. Eine Datenbank mit dem entsprechenden Umfang an Denormalisierung verringert die Anzahl von Tabellen, die verknüpft werden müssen, ohne dass der Aktualisierungsvorgang unnötig kompliziert wird. Dies stellt häufig einen guten Kompromiss dar.

Hinweis

Sie sollten im Allgemeinen eine Denormalisierung in Betracht ziehen, wenn eine beträchtliche Anzahl von Abfragen Verknüpfungen mit mehr als fünf oder sechs Tabellen erfordert.

Es gibt darüber hinaus noch andere Formen der Datenbanknormalisierung. Angenommen in einer Datenbank sind beispielsweise zwei Tabellen vorhanden: Orders und Order Details. Die Orders-Tabelle enthält Informationen zu einer Kundenbestellung. Die einzelnen Produkte in jeder Bestellung sind in der Order Details-Tabelle enthalten. Sie möchten möglicherweise den Gesamtdollarbetrag für jede Bestellung abfragen. Zunächst bestimmen Sie den Dollarbetrag für jedes Produkt mithilfe der Formel "units * unit price – applicable discount" (Einheiten * Einzelpreis - anwendbarer Rabatt). Dann sortieren Sie die Beträge nach Bestellung. Die Abfrage sieht wie folgt aus:

SELECT "Order ID", SUM("Unit Price" * Quantity * (1.0 - Discount))

AS Total FROM "Order Details"

GROUP BY "Order ID"

Order ID Total

----------------------------------------

10000 108

10001 1363.15000915527

10002 731.800003051758

10003 498.180023193359

10004 3194.19999694824

10005 173.400009155273

10006 87.2000007629395

10007 1405

10008 1171

10009 1530

10010 470

... ...

(1078 rows affected)

Die Berechnung für diese Abfrage ist nicht trivial. Bei einem großen Satz von Bestellungen kann die Abfrage eine lange Zeit in Anspruch nehmen. Die Alternative besteht darin, den Dollarbetrag der Bestellung zum Zeitpunkt ihres Eingangs zu berechnen und dann diesen Betrag in einer Spalte der Orders-Tabelle zu speichern. Bei dieser Herangehensweise muss nur die vorberechnete Spalte abgefragt werden, um die benötigte Information zurückzugeben:

SELECT "Order ID", "Order Total" AS Total FROM Orders

Durch das Erstellen einer vorberechneten Spalte können Sie viel Abfragezeit einsparen. Diese Herangehensweise erfordert allerdings das Verwalten einer zusätzlichen Spalte in der Tabelle.

Zwischen Spalten variabler und fester Länge entscheiden

Beim Entwerfen von Tabellen ist das Verständnis der Bedingungen hilfreich, die beim Verwenden von Spalten variabler im Vergleich zu Spalten fester Länge in Betracht zu ziehen sind. Spalten variabler Länge reduzieren die Datenbankgröße, da in ihnen nur der Istwert gespeichert wird. Spalten fester Länge benötigen immer den vom Schema definierten maximalen Platz, selbst wenn der Istwert leer sein sollte. Der Nachteil von Spalten variabler Länge besteht darin, dass einige Vorgänge nicht so effizient wie auf Spalten fester Länge ausgeführt werden können. Wenn eine Spalte variabler Länge beispielsweise anfangs einen kleinen Umfang aufweist und durch einen UPDATE-Vorgang signifikant vergrößert wird, muss der Datensatz möglicherweise an einen anderen Speicherort verschoben werden. Außerdem werden Datenseiten durch häufige Aktualisierungen mit der Zeit mehr und mehr fragmentiert. Es wird daher empfohlen, Spalten fester Länge zu verwenden, wenn die Datenlängen nicht allzu sehr voneinander abweichen und häufige Aktualisierungen vorgenommen werden.

Kleinere Zeilenlängen erstellen

Die Anzahl von Zeilen, die auf einer Seite Platz finden, hängt davon ab, wie kompakt jede Zeile ist. Eine Seite kann mehr Zeilen aufnehmen, wenn die Zeilen kleiner sind. Daher können durch einen einzelnen Datenträgervorgang für eine Tabelle mit kompakten Zeilen mehr Zeilen abgerufen werden, wodurch der Vorgang effektiver wird. Zusätzlich passen mehr Zeilen in den Speichermodulcache, wodurch sich die potenzielle Trefferrate erhöht. Durch kompakte Zeilen wird auch ungenutzter Speicherplatz auf Datenseiten vermieden. Dies kommt häufig bei großen Zeilen vor.

Stellen Sie sich dieses extreme Beispiel vor: Wenn der Datensatz größer als ungefähr die Hälfte einer Datenseite ist, wird fast die Hälfte des Speicherplatzes auf jeder Datenseite unnötig belegt. Einige Datenbankdesigner neigen zu einem Entwurf mit großen Tabellen und portieren das Mainframe-Datenbankschema herunter auf das Gerät. Dies ist möglicherweise kein effizienter Entwurf. Eine mögliche Herangehensweise besteht im Aufteilen der kritischsten Tabellen. Angenommen Sie verfügen über eine Tabelle mit einigen sehr stabilen Werten und anderen, die sich häufig ändern. Es ist sinnvoll, die Tabelle in zwei Tabellen aufzuspalten: eine mit den häufig referenzierten Spalten und die andere mit den stabilen Spalten. Durch das Erstellen von zwei Tabellen können Sie alle Vorteile der kleineren Zeilenlänge nutzen. Der Nachteil besteht darin, dass eine Verknüpfung zum Kombinieren der Informationen notwendig ist.

Kleinere Schlüssellängen verwenden

Ein Index ist eine sortierte Teilmenge der Tabelle, für die der Index erstellt wird. Er ermöglicht eine schnelle Bereichssuche und eine Sortierreihenfolge. Kleinere Indexschlüssel benötigen weniger Speicherplatz und sind effektiver als größere Schlüssel. Eine besonders bewährte Praxis ist es, den Primärschlüssel kompakt zu halten, da auf ihn häufig als Fremdschlüssel in anderen Tabellen verwiesen wird. Wenn kein natürlicher kompakter Primärschlüssel vorhanden ist, können Sie stattdessen eine Identitätsspalte verwenden, die als ganze Zahl implementiert ist.

Ein Index mit einer Schlüsselspalte oder nur wenigen Schlüsselspalten wird als schmaler Index bezeichnet. Ein Index mit vielen Schlüsselspalten wird als breiter Index bezeichnet. Ein breiter Index steht häufig mit einer großen Schlüssellänge in Zusammenhang. Ein extremes Beispiel ist ein Index, der jede Spalte in der Tabelle umfasst. Durch das Erstellen eines solchen Indexes wird effektiv ein Duplikat der Originaltabelle erzeugt. Dies ist sowohl im Hinblick auf die Datenbankgröße als auch im Hinblick auf die Abfrageleistung ineffizient.

Veröffentlichungsartikeltypen und -optionen

Wenn Sie eine Veröffentlichung in SQL Server 2008 erstellen, können Sie zwei Optionen für die Artikel in der Veröffentlichung auswählen.Die folgenden Optionen, mit denen das Filtern und der Datenfluss zwischen dem Verleger und dem Abonnenten gesteuert wird, stehen zur Verfügung:

  • Nur herunterladbar (Schreibgeschützt)
    Es kann zu Situationen kommen, in denen die Daten, die auf Ihrem intelligenten Gerät angezeigt werden sollen, nur in Nachschlagetabellen gespeichert werden. Ihre Benutzer müssen beispielsweise das Firmenverzeichnis auf ihrem intelligenten Gerät durchsuchen, sollen aber nicht dazu in der Lage sein, diese Informationen zu bearbeiten und zu ändern. Der nur herunterladbare Artikeltyp ist für diese Verwendung geeignet. Er ist kleiner, da keine Metadaten auf dem Gerät gespeichert werden, und der Netzwerkverkehr wird während der Synchronisierung reduziert.
  • Gut partitioniert
    Mit gut partitionierten Artikeln in SQL Server 2008 werden die hochgeladenen Änderungen nur der einzelnen Partitions-ID zugeordnet. Dies ist schneller, unterliegt allerdings einigen Einschränkungen:
    • Jede Zeile im Artikel darf nur zu einer Partitions-ID gehören.
    • Jeder Artikel darf nur in einer einzigen Veröffentlichung veröffentlicht werden.
    • Der Abonnent kann nur Zeilen einfügen, die zu seiner Partitions-ID gehören.
    • Gut partitionierte Artikel wirken sich auch auf das Filtern aus. Die folgenden Einschränkungen beziehen sich auf das Filtern:
    • Ein Abonnent kann keine Spalten aktualisieren, die vom Filtern betroffen sind.
    • In einer Verknüpfungsfilterhierarchie kann ein regulärer Artikel keinem gut partitionierten Artikel übergeordnet sein.
    • Der Wert von join_unique_key des Verknüpfungsfilters, in dem ein gut partitionierter Artikel untergeordnet ist, muss 1 sein.
    • Jeder Artikel kann nur eine Teilmenge oder einen Verknüpfungsfilter aufweisen. Der Artikel darf einen Teilmengenfilter aufweisen und einem Verknüpfungsfilter übergeordnet sein, aber nicht einen Teilmengenfilter aufweisen und einem Verknüpfungsfilter untergeordnet sein.

Siehe auch

Konzepte

Optimieren der Abfrageleistung (SQL Server Compact)

Andere Ressourcen

Verbessern der Leistung (SQL Server Compact)

Hilfe und Informationen

Informationsquellen (SQL Server Compact 3.5 Service Pack 1)