@drboboev

Как лучше организовать сущности в Doctrine?

Добрый день.

Имеется приложение, которое предназначено для планирования продаж.
Есть список территорий (entity: Territory)
Есть список продуктов (entity: Product)
Есть тип записей (первичные продажи, вторичные продажи, АКБ) (entity: EntryType)
Есть собственно сами записи (entity: Entry)

Задача приложения: на основании фактических данных посчитать по формуле (и много чего другого) планы на следующий год по каждому продукту и по каждой территории.

Взял Excel-Bundle для парсинга excel файлов. Решено было загружать фактические данные из excel файлов по каждой территории за год.

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

Спасибо.
  • Вопрос задан
  • 250 просмотров
Решения вопроса 2
BlackBride
@BlackBride
Web developer
Не совсем ясно, "много" - это сколько? Много каких запросов? Insert, update, select c кучей join?

Могу предположить, что раз уж упоминается парсинг excel-файлов, то имеются в виду insert-запросы, но ведь doctrine в симфони умеет делать "много раз persist, один раз flush" для оптимизации вставки данных в базу одним запросом.

Если же при построении каких-то данных-графиков нужно много данных, то тут есть варианты с кэшированием, с обработкой данных параллельно в фоновых процессах (Enqueue Bundle, например). Собственно, и при долгом импорте тоже ему можно найти применение.
Ответ написан
Комментировать
@Flying
Если список типов у вас статический - замените EntryType на наследуемые entities через discriminator map, количество запосов это не снизит, но снизит количество join'ов и таблиц. Вот здесь можно подробнее почитать про него на русском.

А вообще судя по задаче у вас основная работа идёт не на уровне строк таблиц, а на уровне их анализа, Doctrine в этом случае - не лучшее решение т.к. задача больше про построение запросов, а не про удобную работу с сильно связанными данными. Тот же Excel с этим справится гораздо лучше :)
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
@galliard
Ну, EntryType, возможно, можно не делать сущностью.

А вообще преждевременная оптимизация - корень всех зол.
Ответ написан
Комментировать
FanatPHP
@FanatPHP
Чебуратор тега РНР
Для столь короткого описания сущности спроектированы верно.

Какое отношение к этому имеет количество запросов в БД - загадка.
Ответ написан
Комментировать
@drboboev Автор вопроса
FanatPHP , Ольга Свистунова insert запросы при парсинге. У меня сущность Entry содержала в себе поля product_id, territory_id, month, sum что означает, что записи записывались отдельно по каждой территории/месяцу/продукту/типу записи отдельной строкой в БД. И при записи получается много запросов и при выборке уже имеющихся данных из БД получается затратно.

Решил сделать иначе, изменил month на year, изменил тип поля sum с int на json_array, храню в БД одной строкой данные за весь год, при грубом расчёте количество запросов к БД при insert сократилось в 12 раз. и при выборке тоже, именно время взаимодействия с БД сократилось, в контроллере происходит конвертация json в array, что не занимает много времени.

Не знаю, можно ли еще как то оптимизировать количество запросов и скорость выполнения.

P.S. При insert запросе "flush" один.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы