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

Question

[drboboev]

Добрый день.

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

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

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

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

Спасибо.

Answer 1

[Ольга Свистунова]

Не совсем ясно, "много" - это сколько? Много каких запросов? Insert, update, select c кучей join?

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

Если же при построении каких-то данных-графиков нужно много данных, то тут есть варианты с кэшированием, с обработкой данных параллельно в фоновых процессах (Enqueue Bundle, например). Собственно, и при долгом импорте тоже ему можно найти применение.

Answer 2

[Flying]

Если список типов у вас статический - замените EntryType на наследуемые entities через discriminator map, количество запосов это не снизит, но снизит количество join'ов и таблиц. Вот здесь можно подробнее почитать про него на русском.

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

Comments

[drboboev]

Список типов не статический. Точнее он не совсем статический. Сегодня в рамках задачи он статический, но завтра могут добавиться еще типы. А могут и не добавиться.

Возможно мне стоит решать проблему не со стороны Doctrine, а со стороны MySQL (PostgreSQL), использовать представления и т.п., а доктриной просто вытаскивать уже готовые данные.

Насчёт задачи - ну как бы да, мне нужно написать приложение, которое на основе определенного количества вводных данных автоматически высчитает конечные данные. Задача: сократить большое количество "бумажной" работы, упростить многие процессы. В итоге, работа должны быть построена так - ответственный сотрудник загружает вводные, на выходе получает конечные данные, и ему при этом не надо использовать бумагу, ручку, калькулятор, эксель и прочее :)

[Flying]

Doctrine хорошо работает если вам необходимо организовать данные со сложной структурой. Если же вам необходима в основном аггрегация данных (а похоже на то) - то Doctrine вам вряд ли будет полезна

Answer 3

[galliard]

Ну, EntryType, возможно, можно не делать сущностью.

А вообще преждевременная оптимизация - корень всех зол.

Answer 4

[FanatPHP]

Для столь короткого описания сущности спроектированы верно.

Какое отношение к этому имеет количество запросов в БД - загадка.

Answer 5

[drboboev]

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

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

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

P.S. При insert запросе "flush" один.

Comments

[FanatPHP]

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

[drboboev]

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

[FanatPHP]

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

[drboboev]

FanatPHP, получил? от тебя? давай посмотрим

Для столь короткого описания сущности спроектированы верно.

Какое отношение к этому имеет количество запросов в БД - загадка.

потом я расписал каким образом хранятся данные и как я их потом выдёргиваю. а ты в ответ:

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

это всё, что я от тебя получил. единственное полезное предложение от тебя это:

Для столь короткого описания сущности спроектированы верно.

а всё остальное - ответ ради ответа. а не для помощи. если ты на все вопросы так отвечаешь, то зачем вообще этим заниматься - загадка

[FanatPHP]

Мальчик, ты путаешься в показаниях.
Как данные у тебя хранятся, ты написал в самом начале. Нормальная реляционная структура.
А "потом" ты расписал совсем другое - то, как ты испортил изначально хорошую структуру данных. А теперь пытаешься мне втереть, что так все и было изначально. Лгать нехорошо. Скажи родителям, чтобы поставили тебя в угол

[drboboev]

FanatPHP, я ничего не "портил". я просто изменил тип поля в сущности Entry, о чем и написал. теперь, чтобы записать данные по одной территории за год, я использую одну запись вместо 12. так что я не "лгал". я просто написал что я сделал для оптимизации запросов. а ты вместо того, чтобы указать на ошибки, сказать что так делать не надо, это что то портит и прочее, ты решил съязвить. вот только зачем - непонятно. ты хотел помочь? ну так помоги. а свой "троллинг" оставь для мемов и онлайн игр. и слова "мальчик", "мамочка", "родители" используй там же.

[FanatPHP]

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