Клиентские приложения точки продажи (POS)
Клиентские приложения точки продажи (POS) — это программы, с которыми клиентам приходится прямо или косвенно работать на точках продажи. Примеры включают терминалы, используемые кассирами, банкоматами и киосками в магазинах. Эти приложения осуществляют сбор данных на удаленных узлах и передают их на центральный узел, например центральный офис или центр обработки данных. Общим для данных приложений является преимущественный сбор данных в точке продажи с последующей передачей их в центральный офис без конфликтов, поскольку один удаленный пользователь (обычно клиент или продавец) обновляет определенный элемент данных.
Следующий рисунок демонстрирует обычную схему, в которой данные идут в обоих направлениях между центральным узлом и удаленными узлами:
.gif "Репликация данных со складов в штаб-квартиры")
Пример компании Adventure Works Cycles
Adventure Works Cycles — это вымышленная производственная компания, которая используется для демонстрации концепций баз данных и сценариев работы с ними. Дополнительные сведения см. в разделе Образцы баз данных AdventureWorks2008R2.
Многие розничные магазины, торгующие продуктами Adventure Works Cycles, используют системы точек продаж для получения и передачи данных на центральный узел. Обычно данные о прайс-листах продуктов и их наличии на складе передаются в розничный магазин в режиме только для чтения при их обновлении. Сведения о покупках клиентов передаются из каждого розничного магазина на центральный узел.
Общие требования для этого сценария
POS-приложения обычно имеют следующие характеристики, которые необходимо принимать во внимание при разработке соответствующего решения для репликации:
Большинство данных вводится и обновляется на удаленных узлах.
Удаленные пользователи должны иметь возможность выполнения обновлений независимо друг от друга, без необходимости подключения к центральному узлу.
Данные, обновленные на удаленном узле, не обновляются на других узлах, поэтому обычно конфликты не возникают.
Обновление некоторых данных, например данных в таблицах с описаниями продуктов, должно производиться только на центральном узле.
Пользователи синхронизируют данные в запланированное время по расписанию (например, в конце рабочего дня).
Приложение должно контролировать то, как долго удаленный узел может оставаться не синхронизированным.
Для некоторых таблиц необходима фильтрация, чтобы каждый магазин получал различные данные для одной или нескольких таблиц. Например, каждый магазин получает информацию только по имеющимся в нем продуктам.
Это приложение, возможно, нуждается в запуске клиентской бизнес-логики при синхронизации данных.
Это приложение, возможно, нуждается в синхронизации данных через Интернет, а не через выделенное соединение.
Следующая диаграмма иллюстрирует фильтрацию, связанную с этим сценарием:
.gif "Фильтрация для приложений кассовых терминалов")
Типы репликации, доступные для использования в этом сценарии
Microsoft SQL Server использует метафору издательского дела для описания компонентов системы репликации. Компоненты включают издатель, подписчики, публикации, статьи и подписки. На рисунке, показанном выше, центральный узел является издателем. Данные на центральном узле — это публикация, а каждая таблица данных представляет собой статью (статьями могут быть другие объекты базы данных, например хранимые процедуры). Каждая точка продажи является подписчиком публикации, получающим схему и данные в виде подписки. Дополнительные сведения о компонентах системы см. в разделе Обзор модели публикации репликации.
SQL Server предлагает различные виды репликации в соответствии с различными требованиями приложений: репликация моментальных снимков, репликация транзакций и репликация слиянием. Этот сценарий лучше всего реализовывать с помощью репликации слиянием, которая хорошо подходит для соблюдения требований, указанных в предыдущем разделе. Дополнительные сведения о репликации слиянием см. в разделах Обзор репликации слиянием и Как работает репликация слиянием.
Параметры репликации слиянием, важные для этого сценария
Репликация слиянием имеет несколько параметров, направленных на выполнение требований, которые описаны ранее в этом разделе. Следующий список представляет все необходимые требования и параметры репликации слиянием, которые направлены на удовлетворение этих требований.
Большинство данных вводится и обновляется на удаленных узлах.
Репликация слиянием предоставляет эту возможность без определения отдельных параметров.
Удаленные пользователи должны иметь возможность выполнения обновлений независимо друг от друга, без необходимости подключения к центральному узлу.
Репликация слиянием предоставляет эту возможность без определения отдельных параметров.
Данные, обновленные на удаленном узле, не обновляются на других узлах, поэтому обычно конфликты не возникают.
В POS-приложениях часто удается избежать конфликтов, поскольку отдельный пользователь обновляет заданный элемент данных. Так как данные не перекрываются между пользователями, возможна оптимизация производительности при помощи параметра неперекрывающихся секций. Дополнительные сведения см. в подразделе «Установка параметров секций» раздела Параметризованные фильтры строк.
Репликация слиянием предоставляет возможность выявления конфликтов, а также их разрешения в прогнозируемых ситуациях. Дополнительные сведения см. в разделе Обнаружение и разрешение конфликтов репликации слиянием.
Некоторые данные должны обновляться только на центральном узле, например данные в таблицах цен на товары.
Репликация слиянием предоставляет возможность только загрузки статей для тех таблиц, которые должны обновляться только издателем. Дополнительные сведения см. в разделе Оптимизация производительности репликации слиянием при работе со статьями, доступными только для загрузки.
Пользователи должны иметь возможность синхронизировать данные в любое время, не только по расписанию.
Репликация реализует два типа подписки: принудительную и по запросу. Подписка по запросу лучше всего подходит для синхронизации данных по запросу. Дополнительные сведения о типах подписки и синхронизации по расписанию см. в разделах Подписка на публикации и Синхронизация данных.
Приложение должно контролировать то, как долго удаленный узел может оставаться не синхронизированным.
Репликация слиянием позволяет указать время действия подписки, чтобы обеспечить своевременную синхронизацию всех подписчиков. Дополнительные сведения см. в разделе Окончание срока действия и отключение подписки.
Для большинства таблиц необходима фильтрация, чтобы каждый пользователь получал различные данные для одной или нескольких таблиц.
Репликация слиянием позволяет фильтровать столбцы и строки. Фильтры строк могут быть статическими или параметризованными. Статические фильтры применимы только тогда, когда публикация уже создана; результат представляет собой один набор данных. Параметризованные фильтры применяются каждый раз при синхронизации подписчика; результаты помещаются в отдельный набор данных для каждого подписчика. В POS-приложениях часто используются параметризованные фильтры, но могут использоваться и статические фильтры. Дополнительные сведения см. в разделе Фильтрация опубликованных данных для репликации слиянием.
Это приложение, возможно, нуждается в запуске клиентской бизнес-логики при синхронизации данных.
Репликация слиянием позволяет указать код, который будет выполнен во время синхронизации. Этот код может реагировать на широкий диапазон событий и имеет доступ к синхронизируемым данным. Дополнительные сведения см. в разделе Выполнение бизнес-логики при синхронизации слиянием.
Это приложение, возможно, нуждается в синхронизации данных через Интернет, а не через выделенное соединение.
При использовании выпуска SQL Server Compact 3.5 с пакетом обновления 2 (SP2) данные синхронизируются через соединение по протоколам HTTP или HTTPS. Для других выпусков SQL Server можно использовать веб-синхронизацию, которая требует соединения по протоколу HTTPS. Дополнительные сведения см. в разделе Веб-синхронизация для репликации слиянием.
Шаги по реализации этого сценария
Чтобы реализовать этот сценарий, прежде всего необходимо создать публикацию и подписки, а затем инициализировать каждую подписку. Чтобы получить дополнительные сведения по каждому шагу, щелкните ссылки, приводимые ниже:
После того как подписка инициализирована и выполняется обмен данными между издателем и подписчиками, возможно, потребуется ознакомиться с дополнительными сведениями в следующих разделах, в которых рассматриваются общие задачи администрирования и контроля: