Shared стратегия хранения данных для «живой» сводки в Excel VBA

Question

Я делаю пользовательский интерфейс в Excel, который цель состоит в том, чтобы «жить» информации о Orders и Order Status между тремя пользователями, я назову их DataUser, DashboardOne, и DashboardTwo для примера.

Процесс состоит в том, что DataUser заполнит данные «Заказы», ​​данные будут использованы для заполнения информации на двух панелях. Панели мониторинга будут обновляться в реальном времени с изменениями от DataUser (Заказы увеличиваются/уменьшаются) и изменяются в состоянии заказа между DashboardOne и DashboardTwo. Для живых обновлений я думаю об использовании вызова Application.OnTime, чтобы обновить View/Dashboards. Две панели будут активны около 8 часов в день.

Где я борюсь за то, как/где хранить данные, у меня есть несколько вариантов, но я не знаю последствий одного над другим, особенно учитывая, что я намереваюсь, чтобы информационные панели будет запускаться/обновляться каждые 30 секунд. с Application.OnTime, что может оказаться дорогостоящим.

варианты я думал о том, где:

• A Мастер Workbook, который будет создавать отдельные рабочие книги для DashboardOne и DashboardTwo и действовать базы данных и основной интерфейс для DataUser.
• Три отдельные книги, которые будут относиться к одной DataWorkbook или другому плоскому файлу данных (возможно, и XML или JSON).
• Использование фактической базы данных для данных, хотя это может привести к другим последствиям (в настоящее время их нет).

Я не рассматриваю общую книгу, поскольку я пробовал что-то подобное в прошлом (и на этот раз ^^, ранние шаги), и это было довольно плохо, кошмар для синхронизации и плохая целостность данных.

Короче: Какой будет лучшая стратегия хранения данных для Excel, которые не ставят под угрозу целостность данных и не так дорого, чтобы помешать бесперебойной работы остальной части кода? Есть ли лучшие варианты, которые я должен рассмотреть?

Answer 1

Существует множество альтернатив, в зависимости от времени, которое вы хотите инвестировать, и инструментов под рукой. Я дам вам пару вариантов.

Но во-первых, основные допущения:

1. Количество элементов данных, которые нужно разделить (будучи приборной панели) имеет несколько десятков (скажем, менее 100),

2. У вас есть хотя бы базовые навыки программирования,

3. Из вашего описания у вас есть один клиент с возможностями READ-WRITE, в то время как есть два клиента с возможностью READ-ONLY.

ВАРИАНТ 1: Вы можете иметь Excel Сохранение данных в формате CSV (очень небольшое количество данных и, следовательно, это заняло бы малую долю секунды, чтобы сохранить его и прочитать его).

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

1. На одной записи, обработки условия ошибки, когда он пытается записать в то же время один из клиентов пытается читать,

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

Поскольку записи и операции чтения собираются принять очень, очень короткий промежуток времени (как указано, малая доля секунды), эти условия будут очень редко. Дополнительно, поскольку оба клиента панели мониторинга будут открывать файл только для чтения, они не будут мешать друг другу, если они сделают свою попытку в тот же момент.

Если вы хотите резко уменьшить вероятность столкновения, вы можете настроить таймеры (процесса обновления с одной стороны и процессов чтения на другом) на первичное число секунд. Например, таймер процесса обновления будет составлять каждые 11 секунд, а время чтения - каждые 7 секунд.

ВАРИАНТ 2: Установите канал TCP/IP между процессами, где основной процесс (то есть тот, который будет иметь WRITE привилегии) ​​будет посылать инициирующее сообщение к двум другим с просьбой запустить обновление каждый раз, когда новая версия данных была сохранена. После приема триггера оба процесса READ-ONLY будут приближаться к файлу и извлекать данные.

В этом случае шансы столкновения будут близки к нулю.