POS-Anwendungen (Point-of-Sale)
POS-Anwendungen (Point-of-Sale) sind beispielsweise Anwendungen, die der Konsument direkt oder indirekt am Point-of-Sale vorfindet. Hierzu zählen beispielsweise Terminals, die an Kassen, Geldautomaten und Instore-Kiosks verwendet werden. Diese Anwendungen sammeln Daten an Remotestandorten und übertragen diese an einen zentralen Speicherort, beispielsweise an die Zentrale eines Datenzentrums. Für gewöhnlich werden in diesen Anwendungen Daten zunächst am Point-of-Sale gesammelt und ohne Konflikte auf die Zentralen hochgeladen, da ein einzelner Remotebenutzer (normalerweise ein Kunde oder Verkäufer) die angegebenen Daten aktualisiert.
Das folgende Diagramm veranschaulicht ein typisches Szenario, bei dem zwischen dem zentralen Standort und den Remotestandorten ein Datenfluss in beide Richtungen stattfindet:
.gif "Replizieren von Daten von Geschäften zur Zentrale")
Beispiel mit Adventure Works Cycles
Adventure Works Cycles ist eine zum Demonstrieren von Datenbankkonzepten und -szenarien erfundene Produktionsfirma. Weitere Informationen finden Sie unter AdventureWorks2008R2-Beispieldatenbanken.
Viele der Einzelhandelsgeschäfte, die Produkte von Adventure Works Cycles verkaufen, verwenden Point-of-Sale-Systeme, die Daten von einem zentralen Standort empfangen und Daten an diesen übertragen. Normalerweise werden schreibgeschützte Daten zu den Produktpreisen und Lagerbeständen an das Einzelhandelsgeschäft gesendet, wenn diese aktualisiert werden. Informationen zu Kundenkäufen werden von den Einzelhandelsgeschäften an die Zentrale übertragen.
Allgemeine Anforderungen für dieses Szenario
POS-Anwendungen haben normalerweise folgende Merkmale, die bei einer geeigneten Replikation berücksichtigt werden müssen:
Die meisten Daten werden an den Remotestandorten eingegeben und aktualisiert.
Remotebenutzer müssen in der Lage sein, Aktualisierungen unabhängig durchzuführen, ohne dass eine Verbindung mit dem zentralen Standort vorliegen muss.
Daten, die an einem Remotestandort hochgeladen werden, werden an keinem anderen Standort aktualisiert. Demzufolge treten normalerweise keine Konflikte auf.
Einige Daten, wie beispielsweise Produktbeschreibungstabellen, sollten nur am zentralen Standort aktualisiert werden.
Benutzer synchronisieren Daten zu geplanten Zeitpunkten (z. B. am Ende eines Geschäftstages).
Die Anwendung muss steuern, wie lange ein Remotestandort unsynchronisiert bleiben darf.
Für einige Tabellen ist eine Filterung erforderlich, sodass die einzelnen Filialen für eine oder mehrere Tabellen verschiedene Daten erhalten. Jede Filiale erhält beispielsweise nur Informationen zu den Produkten, die sie auf Lager hat.
Gegebenenfalls muss die Anwendung beim Synchronisieren von Daten benutzerdefinierte Geschäftslogik ausführen.
Die Anwendung muss möglicherweise Daten über das Internet und nicht über eine Standleitung synchronisieren.
Folgendes Diagramm zeigt die Filterung für dieses Szenario:
.gif "Filtern für Point-of-Sale-Anwendungen")
Typ der für dieses Szenario zu verwendenden Replikation
Microsoft SQL Server verwendet ein Modell, das sich auf Abläufe aus dem Verlagswesen stützt, um die Komponenten des Replikationssystems zu beschreiben. Zu den Komponenten zählen der Verleger, der Abonnent, Veröffentlichungen und Artikel sowie Abonnements. In dem oben stehenden Diagramm fungiert der zentrale Standort als Verleger. Die am zentralen Standort vorhandenen Daten sind die Veröffentlichung, wobei jede Datentabelle einen Artikel darstellt (Artikel können auch andere Datenbankobjekte sein, z. B. gespeicherte Prozeduren). Jeder Point-of-Sale-Terminal ist ein Abonnent der Veröffentlichung, der das Schema und Daten als Abonnement erhält. Weitere Informationen zu den Komponenten des Systems finden Sie unter Das Replikationsveröffentlichungsmodell (Übersicht).
SQL Server bietet verschiedenen Replikationstypen für unterschiedliche Anwendungsanforderungen: die Snapshotreplikation, die Transaktionsreplikation und die Mergereplikation. Für dieses Szenario wird am besten die Mergereplikation implementiert, da hiermit die im vorherigen Abschnitt aufgeführten Anforderungen am besten erfüllt werden. Weitere Informationen zur Mergereplikation finden Sie unter Mergereplikation (Übersicht) and Funktionsweise der Mergereplikation.
Relevante Mergereplikationsoptionen für dieses Szenario
Die Mergereplikation bietet verschiedene Optionen, um die oben in diesem Thema beschriebenen Anforderungen zu erfüllen: Die folgende Liste enthält die einzelnen Anforderungen und die Mergereplikationsoption, die auf die jeweilige Anforderung ausgerichtet ist.
Die meisten Daten werden an den Remotestandorten eingegeben und aktualisiert.
Die Mergereplikation ist hierauf ausgerichtet, ohne dass bestimmte Optionen angegeben werden müssen.
Remotebenutzer müssen in der Lage sein, Aktualisierungen unabhängig durchzuführen, ohne dass eine Verbindung mit dem zentralen Standort vorliegen muss.
Die Mergereplikation ist hierauf ausgerichtet, ohne dass bestimmte Optionen angegeben werden müssen.
Daten, die an einem Remotestandort hochgeladen werden, werden an keinem anderen Standort aktualisiert. Demzufolge treten normalerweise keine Konflikte auf.
In POS-Anwendungen werden Konflikte häufig vermieden, da ein einzelner Benutzer bestimmte Daten aktualisiert. Da es keine Datenüberlappung zwischen Benutzern gibt, kann die Leistung mithilfe der Option für nicht überlappende Partitionen optimiert werden. Weitere Informationen finden Sie im Abschnitt zum Festlegen von Partitionsoptionen im Thema Parametrisierte Zeilenfilter.
Die Mergereplikation bietet eine Konflikterkennung und -lösung für Fälle, in denen Datenkonflikte erwartet werden. Weitere Informationen finden Sie unter Erkennen und Beseitigen von Konflikten bei der Mergereplikation.
Einige Daten, wie beispielsweise Preistabellen, sollten nur am zentralen Standort aktualisiert werden.
Die Mergereplikation liefert nur heruntergeladene Artikel für Tabellen, die nur auf dem Verleger aktualisiert sein sollten. Weitere Informationen finden Sie unter Optimieren der Leistung der Mergereplikation durch nur herunterladbare Artikel.
Benutzer sollten in der Lage sein, Daten bei Bedarf und nicht nur zu geplanten Zeitpunkten zu synchronisieren.
Die Replikation umfasst zwei Abonnementtypen: Pushabonnements und Pullabonnements. Pullabonnements eignen sich besser für die bedarfsgesteuerte Synchronisierung. Weitere Informationen zu den Abonnementtypen und zur Planung der Synchronisierung finden Sie unter Abonnieren von Veröffentlichungen und Synchronisieren von Daten.
Die Anwendung muss steuern, wie lange ein Remotestandort unsynchronisiert bleiben darf.
Bei der Mergereplikation können Sie einen Zeitraum für den Abonnementablauf festlegen, um sicherzustellen, dass alle Abonnenten innerhalb eines bestimmten Zeitraums eine Synchronisierung ausführen. Weitere Informationen finden Sie unter Abonnementablauf und -deaktivierung.
Für die meisten Tabellen ist eine Filterung erforderlich, sodass die einzelnen Benutzer für eine oder mehrere Tabellen verschiedene Daten erhalten.
Die Mergereplikation ermöglicht eine spalten- und zeilenbezogene Filterung. Zeilenfilter können statisch oder parametrisiert sein. Ein statischer Filter wird nur angewendet, wenn eine Veröffentlichung erstellt wird. Als Ergebnis wird ein Dataset ausgegeben. Ein parametrisierter Filter wird jedes Mal angewendet, wenn ein Abonnent synchronisiert wird. Als Ergebnis werden verschiedene Datasets für die jeweiligen Abonnenten ausgegeben. POS-Anwendungen verwenden häufig parametrisierte Filter, können aber auch statische Filter verwenden. Weitere Informationen finden Sie unter Filtern veröffentlichter Daten für die Mergereplikation.
Gegebenenfalls muss die Anwendung beim Synchronisieren von Daten benutzerdefinierte Geschäftslogik ausführen.
Bei Mergereplikationen kann ein Code angegeben werden, der während der Synchronisierung ausgeführt werden soll. Dieser Code kann auf eine breite Palette an Ereignissen reagieren und hat Zugriff auf die zu synchronisierenden Daten. Weitere Informationen finden Sie unter Ausführen der Geschäftslogik während der Mergesynchronisierung.
Die Anwendung muss möglicherweise Daten über das Internet und nicht über eine Standleitung synchronisieren.
Bei der Verwendung von SQL Server Compact 3.5 SP2 werden Daten über eine HTTP- oder HTTPS-Verbindung synchronisiert.Bei anderen Editionen von SQL Server können Sie die Websynchronisierung verwenden, die HTTPS erfordert. Weitere Informationen finden Sie unter Websynchronisierung für die Mergereplikation.
Schritte für die Implementierung dieses Szenarios
Für die Implementierung dieses Szenario müssen Sie zunächst eine Veröffentlichung und Abonnements erstellen und anschließend die einzelnen Abonnements initialisieren. Klicken Sie auf die folgenden Links, um weitere Informationen zu den einzelnen Schritten zu erhalten:
Wenn das Abonnement initialisiert ist und die Daten zwischen dem Verleger und den Abonnenten fließen, benötigen Sie möglicherweise Informationen zu allgemeinen Verwaltungs- und Überwachungsaufgaben. Diese Informationen finden Sie in den folgenden Themen: