Эффективная синхронизация складской информации

0

Хорошо, посмотрим, помогут ли вам Wizards с этой проблемой, я ударяю головой.

Сценарий - довольно стандартная настройка с точкой продажи (где я) и backoffice, отслеживающая информацию о складах. Проблема в том, что мне нужно синхронизировать базу данных в точке продажи с текущей информацией о запасах от задней панели. Сейчас это делается путем извлечения каталога из backoffice через Web. Каталог содержит информацию, такую ​​как доступные в настоящее время единицы, текущую цену и уникальные идентификаторы для каждого типа. В моей базе данных у меня есть точная информация, и я обновляю ее после извлечения каталога. Для меня важно вставлять новые типы устройств по мере их появления, обновлять уже существующие типы с информацией о доступности и ценой и, наконец, удалять типы (или помечать их недоступными), когда они идут ниже определенного порога.

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

INSERT INTO store (id, quantity, price)VALUES(x, y, z)
ON DUPLICATE KEY quantity=y, price=z;

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

Есть ли более быстрое решение этой проблемы?

  • 0
    Соединяется ли frontoffice напрямую с базой данных backoffice или с каким-либо веб-сервисом типа XML?
  • 0
    Он проходит через простой веб-интерфейс с действительно глупым синтаксисом вывода, но я могу разобрать его хорошо.
Теги:
synchronization

2 ответа

1
Лучший ответ
REPLACE INTO store (id, quantity, price) VALUES (x, y, z), (x2,y2,z2);

Я также предлагаю не отправлять их в webapp как SQL (ужасная безопасность) и отправлять их в виде больших партий (по 1000 строк за раз) в некотором формате, в котором вам удобно. Webapp выполняет все действия REPLACE и возвращает успех.

  • 0
    Это настолько близко, насколько это возможно :-) К сожалению, я не могу сказать, как должен выглядеть интерфейс между офисами, в противном случае я бы позволил только обновления быть переданы из бэк-офиса для меня. Данные представляют собой странный файл с разделителями каналов, который не был бы таким уж плохим, если бы они также не объединяли строки, используя каналы, что делает необходимым подсчет элементов, чтобы знать, в какой записи мы находимся :-(
0

INSERT INTO store (id, quantity, price) VALUES (x, y, z), (x2,y2,z2)

Но я не знаю, как это jives с вашим выражением ON DUPLICATE KEY... вы можете выполнить некоторую логику, чтобы разделить данные на группы для обновления и вставить самостоятельно.

  • 0
    ON DUPLICATE будет разрушаться многострочными вставками, я мог бы сначала попытаться получить Ids, но это только увеличило бы нагрузку на мою БД, не так ли?
  • 0
    Ну, это зависит от того, сколько предметов мы говорим, но при условии, что вы выбираете первичный ключ и возвращаете только один столбец, я не думаю, что это будет так ужасно. Но я думаю, что вам нужно будет либо выполнить большое чтение, а затем отсортировать их заранее, чтобы выполнить множественную вставку, либо вам придется вставлять их по одному с автоматическим восстановлением после сбоя для существующих записей.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню