Как бывший архитектор системы, которая также активно использовала базу данных в качестве «хаба», я могу сказать, что есть несколько недостатков, о которых вы должны знать. В нашей системе используются базы данных:
- В качестве хранилища транзакций (типичный OLTP-материал)
- В качестве промежуточной очереди (отправленные, но необработанные транзакции)
- Как хранилище исторических данных (результаты обработанных транзакций)
- в качестве уровня взаимодействия (непереведенные команды или транзакции, выполненные из других систем)
Одним из основных недостатков является стоимость владения. Когда ваши базы данных становятся единственной точкой отказа для стольких типов операций, становится необходимым убедиться, что все они размещены в средах высокой доступности. Это не только дорого с аппаратной точки зрения, но и дорого поддерживать развертывание в средах высокой доступности, поскольку разработчики обычно имеют очень ограниченный обзор внутренних компонентов.
Вторым недостатком является то, что вы должны серьезно продумать целостность всех ваших таблиц. В типичной среде SOA вы полностью контролируете изменение данных. Когда вы предоставляете его через таблицы базы данных, вы должны учитывать, что любое приложение с правильными учетными данными будет иметь возможность изменять данные. Из-за этого вы должны тщательно рассмотреть утилитарные реализации ограничений. Если бы у вас был единственный сервис, управляющий постоянством, вы могли бы значительно ослабить ограничения на базу данных и применить их в коде.
В-третьих, если вы когда-нибудь захотите раскрыть какую-либо функциональность, которую таблицы базы данных в настоящее время позволяют вам предоставлять сторонним организациям, вы все равно должны написать служебный код, чтобы вам было удобнее делать это стратегически, а не реагировать на запросы.
В-четвертых, взаимодействие пользовательского интерфейса напрямую с уровнем данных создает риски для безопасности, особенно если клиент является толстым клиентом.
Наконец, написание кода, который отвечает на события (сервисные вызовы), намного проще, чем опросный код. Как правило, организации, которые в значительной степени полагаются на опрос базы данных, заканчивают тем, что изобретают колесо каждый раз, когда новый проект требует новой «службы мониторинга». Этого можно избежать, создав «основу», но у них есть свои подводные камни (в первую очередь в отношении рецепта против усыновления).
Это просто список проблем, с которыми я столкнулся. Это не обязательно должно отговаривать вас от использования баз данных для этих функций, но это помогает заранее знать об опасностях, чтобы вы могли по крайней мере планировать их, если они когда-нибудь станут проблемой.
EDIT
Просто подумал о другом сценарии, который причинял нам боль. Создание версий ваших изменений может быть затруднено. Например, если вам нужно изменить форму таблицы (нормализовать / денормализовать), она будет иметь каскадный эффект, если несколько приложений используют ее. В сценарии SOA это намного проще, потому что вы можете сохранить свой старый API, изменить внутреннее взаимодействие, чтобы оно работало с измененными таблицами, и позволить потребителям переходить на новую версию по своему собственному расписанию.