PHP-приложение для настольного приложения

Question

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

Приложение будет использоваться множеством людей нашей компании, поэтому мы подумали об установке на их компьютеры веб-сервера (Apache) и сделать приложение запущенным на своих машинах. Проблема заключается в том, что, если мы решим идти по этому пути, мы должны:

• Скачать все данные из MySQL ПЕРЕД запуска приложения (когда пользователь имеет доступ к Интернету) и сохранить эти данные в формат JSON файл
  • Изменить все запросы в проекте для того, чтобы принять данные из JSON вместо базы данных
  • Кроме того, есть много функций, которые вставляют в базу данных в режиме реального времени, так мы должны будем использовать SQLite, а затем передать данные в базу данных MySQL
  • И, наконец, люди, которые используют эту программу, будут иметь доступ ко всем файлам PHP, и они могут изменить их в любое время.

У нас нет времени, чтобы думать о реальном приложении Desktop Java, потому что это приложение будет использоваться, начиная с января, поэтому у нас нет времени, чтобы развивать его.

У вас есть предложения? Есть ли что-то, о чем я не думаю, или технология, которая может мне помочь? Спасибо!

PS. Я рассмотрел такие программы, как NightRain из PHP Desktop, но они только избежать установки Apache, ничего больше ...

Answer 1

Введение

Поскольку вы, очевидно, необходимо быстрое решение, я дам вам один. Это основано на информации, которую мы знаем. Предупреждение, это решение не изящно, и вам НЕОБХОДИМО заменить его, когда вы получаете шанс.

Решение

1. Очистить все ваши первичные и внешние ключи.
2. Заменить их BINARY(16) с индексом.

Для каждой записи потребуется псевдо-первичный ключ, который будет генерироваться случайным образом с помощью CSRNG, двоичный 16 просто удобен для соблюдения стандарта UUID. Это гарантирует, что каждая новая запись останется однозначно проиндексированной, несмотря на отсутствие знаний о других дистрибутивах.

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

3. Для каждого ноутбука потребуется копия всей базы данных.
4. Каждому ноутбуку разрешено добавлять новые данные, никогда не удалять или изменять базовые данные.

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

5. Новые данные следует рассматривать как «обновления» на основе их метки времени.

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

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

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

Заключение

Я хотел бы использовать только это решение, если у меня действительно было слишком. Фактически, я бы оценил только 80% -ный шанс даже работать с нестандартным качеством. Он также предполагает, что вы можете выделить все оставшееся время разработки для повторного факторизации методов вставки данных.

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

Каждая новая функция должна быть обратно совместима со старыми данными.