Поделиться через


Клиентские приложения точки продажи (POS)

Клиентские приложения точки продажи (POS) — это программы, с которыми клиентам приходится прямо или косвенно работать на точках продажи. Примеры включают терминалы, используемые кассирами, банкоматами и киосками в магазинах. Эти приложения осуществляют сбор данных на удаленных узлах и передают их на центральный узел, например центральный офис или центр обработки данных. Общим для данных приложений является преимущественный сбор данных в точке продажи с последующей передачей их в центральный офис без конфликтов, поскольку один удаленный пользователь (обычно клиент или продавец) обновляет определенный элемент данных.

Следующий рисунок демонстрирует обычную схему, в которой данные идут в обоих направлениях между центральным узлом и удаленными узлами:

Репликация данных со складов в штаб-квартиры

Пример компании Adventure Works Cycles

Adventure Works Cycles — это вымышленная производственная компания, которая используется для демонстрации концепций баз данных и сценариев работы с ними. Дополнительные сведения см. в разделе Образцы баз данных AdventureWorks2008R2.

Многие розничные магазины, торгующие продуктами Adventure Works Cycles, используют системы точек продаж для получения и передачи данных на центральный узел. Обычно данные о прайс-листах продуктов и их наличии на складе передаются в розничный магазин в режиме только для чтения при их обновлении. Сведения о покупках клиентов передаются из каждого розничного магазина на центральный узел.

Общие требования для этого сценария

POS-приложения обычно имеют следующие характеристики, которые необходимо принимать во внимание при разработке соответствующего решения для репликации:

  • Большинство данных вводится и обновляется на удаленных узлах.

  • Удаленные пользователи должны иметь возможность выполнения обновлений независимо друг от друга, без необходимости подключения к центральному узлу.

  • Данные, обновленные на удаленном узле, не обновляются на других узлах, поэтому обычно конфликты не возникают.

  • Обновление некоторых данных, например данных в таблицах с описаниями продуктов, должно производиться только на центральном узле.

  • Пользователи синхронизируют данные в запланированное время по расписанию (например, в конце рабочего дня).

  • Приложение должно контролировать то, как долго удаленный узел может оставаться не синхронизированным.

  • Для некоторых таблиц необходима фильтрация, чтобы каждый магазин получал различные данные для одной или нескольких таблиц. Например, каждый магазин получает информацию только по имеющимся в нем продуктам.

  • Это приложение, возможно, нуждается в запуске клиентской бизнес-логики при синхронизации данных.

  • Это приложение, возможно, нуждается в синхронизации данных через Интернет, а не через выделенное соединение.

Следующая диаграмма иллюстрирует фильтрацию, связанную с этим сценарием:

Фильтрация для приложений кассовых терминалов

Типы репликации, доступные для использования в этом сценарии

Microsoft SQL Server использует метафору издательского дела для описания компонентов системы репликации. Компоненты включают издатель, подписчики, публикации, статьи и подписки. На рисунке, показанном выше, центральный узел является издателем. Данные на центральном узле — это публикация, а каждая таблица данных представляет собой статью (статьями могут быть другие объекты базы данных, например хранимые процедуры). Каждая точка продажи является подписчиком публикации, получающим схему и данные в виде подписки. Дополнительные сведения о компонентах системы см. в разделе Обзор модели публикации репликации.

SQL Server предлагает различные виды репликации в соответствии с различными требованиями приложений: репликация моментальных снимков, репликация транзакций и репликация слиянием. Этот сценарий лучше всего реализовывать с помощью репликации слиянием, которая хорошо подходит для соблюдения требований, указанных в предыдущем разделе. Дополнительные сведения о репликации слиянием см. в разделах Обзор репликации слиянием и Как работает репликация слиянием.

Параметры репликации слиянием, важные для этого сценария

Репликация слиянием имеет несколько параметров, направленных на выполнение требований, которые описаны ранее в этом разделе. Следующий список представляет все необходимые требования и параметры репликации слиянием, которые направлены на удовлетворение этих требований.

  • Большинство данных вводится и обновляется на удаленных узлах.

    Репликация слиянием предоставляет эту возможность без определения отдельных параметров.

  • Удаленные пользователи должны иметь возможность выполнения обновлений независимо друг от друга, без необходимости подключения к центральному узлу.

    Репликация слиянием предоставляет эту возможность без определения отдельных параметров.

  • Данные, обновленные на удаленном узле, не обновляются на других узлах, поэтому обычно конфликты не возникают.

    В POS-приложениях часто удается избежать конфликтов, поскольку отдельный пользователь обновляет заданный элемент данных. Так как данные не перекрываются между пользователями, возможна оптимизация производительности при помощи параметра неперекрывающихся секций. Дополнительные сведения см. в подразделе «Установка параметров секций» раздела Параметризованные фильтры строк.

    Репликация слиянием предоставляет возможность выявления конфликтов, а также их разрешения в прогнозируемых ситуациях. Дополнительные сведения см. в разделе Обнаружение и разрешение конфликтов репликации слиянием.

  • Некоторые данные должны обновляться только на центральном узле, например данные в таблицах цен на товары.

    Репликация слиянием предоставляет возможность только загрузки статей для тех таблиц, которые должны обновляться только издателем. Дополнительные сведения см. в разделе Оптимизация производительности репликации слиянием при работе со статьями, доступными только для загрузки.

  • Пользователи должны иметь возможность синхронизировать данные в любое время, не только по расписанию.

    Репликация реализует два типа подписки: принудительную и по запросу. Подписка по запросу лучше всего подходит для синхронизации данных по запросу. Дополнительные сведения о типах подписки и синхронизации по расписанию см. в разделах Подписка на публикации и Синхронизация данных.

  • Приложение должно контролировать то, как долго удаленный узел может оставаться не синхронизированным.

    Репликация слиянием позволяет указать время действия подписки, чтобы обеспечить своевременную синхронизацию всех подписчиков. Дополнительные сведения см. в разделе Окончание срока действия и отключение подписки.

  • Для большинства таблиц необходима фильтрация, чтобы каждый пользователь получал различные данные для одной или нескольких таблиц.

    Репликация слиянием позволяет фильтровать столбцы и строки. Фильтры строк могут быть статическими или параметризованными. Статические фильтры применимы только тогда, когда публикация уже создана; результат представляет собой один набор данных. Параметризованные фильтры применяются каждый раз при синхронизации подписчика; результаты помещаются в отдельный набор данных для каждого подписчика. В POS-приложениях часто используются параметризованные фильтры, но могут использоваться и статические фильтры. Дополнительные сведения см. в разделе Фильтрация опубликованных данных для репликации слиянием.

  • Это приложение, возможно, нуждается в запуске клиентской бизнес-логики при синхронизации данных.

    Репликация слиянием позволяет указать код, который будет выполнен во время синхронизации. Этот код может реагировать на широкий диапазон событий и имеет доступ к синхронизируемым данным. Дополнительные сведения см. в разделе Выполнение бизнес-логики при синхронизации слиянием.

  • Это приложение, возможно, нуждается в синхронизации данных через Интернет, а не через выделенное соединение.

    При использовании выпуска SQL Server Compact 3.5 с пакетом обновления 2 (SP2) данные синхронизируются через соединение по протоколам HTTP или HTTPS. Для других выпусков SQL Server можно использовать веб-синхронизацию, которая требует соединения по протоколу HTTPS. Дополнительные сведения см. в разделе Веб-синхронизация для репликации слиянием.

Шаги по реализации этого сценария

Чтобы реализовать этот сценарий, прежде всего необходимо создать публикацию и подписки, а затем инициализировать каждую подписку. Чтобы получить дополнительные сведения по каждому шагу, щелкните ссылки, приводимые ниже:

После того как подписка инициализирована и выполняется обмен данными между издателем и подписчиками, возможно, потребуется ознакомиться с дополнительными сведениями в следующих разделах, в которых рассматриваются общие задачи администрирования и контроля: