По моему мнению, наличие двух приложений, использующих напрямую одну и ту же базу данных, - плохой дизайн.
Чем больше приложений используют одну и ту же базу данных, тем больше вероятность
что вы попали в узкие места производительности и что вы не можете легко масштабировать
нагрузка по желанию. Базы данных SQL на самом деле не масштабируются. Вы можете купить
большие машины, но они плохо масштабируются в кластерах!
Затраты на техническое обслуживание и разработку могут увеличиться: разработка сложнее
если приложение должно использовать структуры базы данных, которые не подходят
для поставленной задачи, но должны использоваться, поскольку они уже присутствуют.
Также вероятно, что настройки одного приложения будут иметь
влияние на другие приложения («почему такое ненужное
триггер ??! "/" Нам больше не нужны эти данные! "). Это уже сложно
с одной базой данных для одного приложения, когда разработчики
не знаю / не могу знать все варианты использования.
Администрация становится сложнее: какой объект принадлежит какому
приложение? Хаос нарастает. Где я должен искать свои данные? Который
пользователю разрешено взаимодействовать с какими объектами? Что я могу даровать кому?
Обновление: вам понадобится версия с наименьшим общим знаменателем
для всех приложений, использующих его. Это означает, что определенные приложения
не сможет использовать мощные функции. Вам придется придерживаться
старые версии. Это также немного увеличивает стоимость разработки.
Параллелизм: Можете ли вы быть действительно уверены, что нет хронологических
зависимости между процессами? Что делать, если одно приложение изменяет данные
который устарел или должен был быть изменен другим приложением
первый? А как насчет разных приложений, работающих на тех же таблицах
одновременно?
Я бы предложил вам создать сервисный уровень, который будет отвечать за доступ к базе данных. Затем к этому сервису можно получить доступ разными способами (в качестве альтернативы можно использовать веб-сервис REST).