В настоящее время мы разрабатываем веб-приложение для финансового анализа с использованием PHP (Zend Framework 2) и Doctrine как ORM-Tool (база данных MySQL). Сложные финансовые расчеты выполняются на стороне сервера, поскольку клиент должен быть максимально простым. Данные должны быть доступны практически в режиме реального времени, так как пользователь вводит данные в реальном времени. Все пользовательские данные будут немедленно переданы на сервер.
Для финансовых расчетов нам нужно объединить несколько таблиц с настраиваемой фильтрацией и агрегированием данных. Бизнес-логика и расчеты довольно сложны.
Поэтому мы обеспокоены смешиванием бизнес-логики и правил в наших операторах SQL (принцип инкапсуляции). Даже используя инструмент ORM, некоторые операторы будут на нативном SQL и не будут легко понятны / модифицируемы.
Мы рассматриваем использование ETL или программного обеспечения BI для обработки данных. Но большинство инструментов ETL и программного обеспечения BI написаны на Java, и их интеграция с PHP кажется довольно громоздкой. Мы, команда из 5 разработчиков PHP, мало знакомы с дизайном и обработкой ETL. Самый важный недостаток, который мы видим в ETL, — это время обработки, задержка и актуальность данных.
Рекомендуется ли в нашей ситуации использовать инструмент ETL / программное обеспечение Business Intelligence? Или мы должны придерживаться сложных инструкций Doctrine / SQL и связывать нашу бизнес-логику с SQL?
Большое спасибо за любые идеи или рекомендации.
Я не уверен, что этот вопрос требует мнения. Этот ответ предназначен для того, чтобы дать вам возможность подумать о выборе.
Выбор между «внешним» ETL или «внутренним» ETL зависит от нескольких факторов:
Во многих случаях вы можете достичь тех же целей в базе данных или с помощью внешних инструментов. Преимущество внешних инструментов заключается в том, что они не обременяют сервер базы данных — или, по крайней мере, вы можете управлять им гораздо проще. Кроме того, внешние инструменты предназначены для перемещения данных и их обработки, поэтому они часто предлагают лучшую связь, производительность и отчеты об ошибках.
Тем не менее, если ваши навыки сосредоточены на SQL, то загрузка данных в промежуточные таблицы и выполнение работы в базе данных также жизнеспособны. Я часто нахожу, что предпочитаю делать такую обработку в базе данных, но это зависит от требований проекта.
Других решений пока нет …