1. Изначально предполагается, что клиент будет использовать одну единую центральную БД. Которая будет обслуживать центральный офис, склады и торговые точки. А так же сотрудников работающих с ПО СуперМаг Плюс, СуперМаг Мобайл. Для реализации этой схемы как со стороны ПО, так и со стороны используемой базы данных имеются все инструментарии для обеспечения высокой скорости и надежности решения.
Для распределения нагрузки создаваемой мобильными рабочими местами (а они по нашему мнению будут составлять «львиную долю» всех рабочих мест), используются специальные службы Супермаг Плюс, называемые Сервер приложений. Задача сервера приложений состоит в обслуживании запросов от мобильного рабочего места, и обмен информацией с базой данных. Таким образом исключаются прямые множественные обращения к БД со стороны мобильных рабочих мест. И это существенно сокращает количество активных подключений к базе, снимает нагрузку на процессор сервера и его дисковую подсистему. Т.к. мы понимаем, что один Сервер приложений не может справиться с обслуживанием множества мобильных рабочих мест, существует возможность его горизонтального масштабирования. Создается схема напоминающая куст, в корне которого находится центральный сервер, а на корневых ветвях располагаются Сервера приложений, к которым в свою очередь подключается некоторый выделенный пул Мобильных рабочих мест.
В случае же обнаружения борьбы за ресурсы у стационарных рабочих мест, есть возможность расширенной оптимизации БД, ее штатными средствами и инструментами.
В случае, если аппаратные ресурсы сервера будут полностью задействованы и способов их увеличения найдено не будет. В ПО СуперМаг Плюс можно воспользоваться функционалом, который позволит изменить централизованную схему использования на распределенную схему использования БД. В этом случае, рекомендуется рассмотреть так же кустовой способ размещения вспомогательных серверов. В задачу которых будет входит обслуживание стационарных рабочих мест сгруппированных по городам или регионам.
Если по каким-то причинам центральный сервер перестанет удовлетворять потребностям сотрудников аналитического отдела, в сфере получения оперативной информации (отчеты), есть возможность организации еще одного сервера – Сервер отчетов. Наполнение данными которого будет происходить в автоматическом режиме, без участия пользователей.
2. Торговая система Супермаг Плюс, использует партионный учет в варианте «естественной очереди» по алгоритму - FIFO. Это подразумевает автоматическое списывание партии товаров по дате оприходования. При FIFO сначала списываются партии с более ранней датой оприходования. Т.к. FIFO в некоторых случаях не полностью решает потребности в учете, то в Торговой системе СуперМаг Плюс, существует возможность внесения корректив в работу данного алгоритма. Так при совершении возврата поставщику, пользователь может отклонить желание системы привязать возврат к первой незакрытой партии, а указать требуемую партию вручную (проставить основание, ссылку на конкретный документ прихода). Такой способ простановки оснований обычно используется для возврата и списания товара с небольшим сроком годности (например, хлеб). Это позволяет осуществить возврат товаров именно той партии и по тем ценам, которою ожидает получить обратно поставщик.
Что касается расчета Товародвижения, то в настоящее время период расчета для больших и очень больших баз составляет до 5 часов. Т.е. расчет укладывается в период простоя БД (ночь). В случае, если время расчета увеличивается, а все способы по увеличению аппаратной составляющей сервера и инструментариев БД – использованы. На выбор пользователя предлагается несколько вариантов решения –>
- организация выделенного сервера отчетов;
- механизм предварительно расчета «старых» данных и сохранение их в специальных аналитических таблицах. Таким образом в расчете ТД будет участвовать только свежие данные (например, год), а все заранее рассчитанные данные будут просто использоваться, как уже готовый материал. Период в 1 год, который мы предлагаем держать «открытым», мы определили как период, в котором пользователь может вносить изменения, в случае обнаружения критических ошибок в документообороте. В свою очередь закрытый период изменению не подлежит, данные в нем считаются замороженными. Но, и это ограничение в системе можно обойти – достаточно выполнить функцию «Открытия периода», внести изменения и снова его закрыть.