AZ
У меня выборка по данным где постоянно нужны около 20 таких справочников.
Size: a a a
2020 February 29
AZ
Понятно что в орм я могу сделать свойство без мэппинга в бд и расчёте расшифровки и справочника, но скорость упадёт значительно
AZ
И теперь сравни это с одним стандартным джойном на справочник. Тут орм вообще в схему данных не вписывается
AZ
Если в таблице нет ПК на одно поле орм начинает извращаться
SB
Мне кажется, с упоминанием джойна вы путаете ORM (объектную модель) и отчёты.
GB
орм не серебряная пуля, какие-то вещи на нем просто смысла нет реализовывать. например в медицине все федеральные справочники имеют вид id, name, datebeg, dateend. при этом id повторяющийся и расшифровка name соответственно зависит от диапазона datebeg-dateend, т.е в разные диапазоны времени один и тот же id расшифровывается по разному и вот такое на орме уже делается просто через зад, я бы даже сказал просто не имеет смысла.
составной ключ чтоли? прекрасно ормами обрабатывается. не всеми конечно
GB
данные которые приходят в больших объемах используют именно федеральный формат справочников, т.е переход на какой-то свой формат породит другие проблемы, например обновление справочника, если обычно то это банальный транкейт и батчем заливка всего справочника, а в своем случае надо построчно обходить, сравнивать и обновлять только то что изменилось. Ну и при загрузке данных тоже самое, вместо быстрой загрузки батчем придется анализировать практически построчно для выявления своего собственного id из справочника
справочники при обновлении обычно в виде обновлений приходят. тот же ФИАС. можно обновить то, что обновилось
AZ
составной ключ чтоли? прекрасно ормами обрабатывается. не всеми конечно
ну это не фиас к сожалению :) это медицина
AZ
Мне кажется, с упоминанием джойна вы путаете ORM (объектную модель) и отчёты.
я просто для сравнения показал что там где джойн в обычной схеме прямой работы с данными прекрасно справляется в одну строку, орм нормально не вытягивает
ДП
вот у нас пользователи хотя к одной ентити подключить другую, да там join, но не по ключу, а типа найти последнее предыдущее событие по отношению к текущему, я вот хз как такое в ОРМах сделать (каюсь, не спец), а если сделать, то не думаю, что он будет быстрее sql запроса
ДП
пробовать, конечно, нужно, поэтому и возникают дурные мысли - ОРМ на хранимках )
ДП
зачастую чтобы вытащить таблицу пользователям пару раз в ХП вытянешь данные во временные таблицы, потом только джойнишь, иначе тормоза, короче изголяемся как можем)
AZ
классический орм как мне кажется на хранимках не сделать, ну представь что у тебя структура энтити будет зависеть от каких-то внешних параметров. так как хранимка в зависиомости от параметров может возвращать не только разные по содержанию датасеты но и вообще разные по структуре. дальше, Орм часто используют для веба и рест апи в котором есть PATCH, т.е обновление только нужных полей по указанному id объекта, на прямой работе с таблицей как это сделано у орм никаких проблем, но в хранимку то тебе надо передавать весь набор полей в качестве параметров. Ну и так далее, т.е что-то реализовать можно, но это будет не орм :)
N
вот у нас пользователи хотя к одной ентити подключить другую, да там join, но не по ключу, а типа найти последнее предыдущее событие по отношению к текущему, я вот хз как такое в ОРМах сделать (каюсь, не спец), а если сделать, то не думаю, что он будет быстрее sql запроса
ну, джойнить в ОРМах - на мой взгляд это извращение ))
N
пробовать, конечно, нужно, поэтому и возникают дурные мысли - ОРМ на хранимках )
не ОРМ на хранимках, а просто не надо резать стандартный функционал работы с БД )
AZ
вот у нас пользователи хотя к одной ентити подключить другую, да там join, но не по ключу, а типа найти последнее предыдущее событие по отношению к текущему, я вот хз как такое в ОРМах сделать (каюсь, не спец), а если сделать, то не думаю, что он будет быстрее sql запроса
в ормах это делается введением значения которое не мэппится в базу а вычисляется прямо в классе, ну т.е некое подобие вычисляемого поля
ДП
классический орм как мне кажется на хранимках не сделать, ну представь что у тебя структура энтити будет зависеть от каких-то внешних параметров. так как хранимка в зависиомости от параметров может возвращать не только разные по содержанию датасеты но и вообще разные по структуре. дальше, Орм часто используют для веба и рест апи в котором есть PATCH, т.е обновление только нужных полей по указанному id объекта, на прямой работе с таблицей как это сделано у орм никаких проблем, но в хранимку то тебе надо передавать весь набор полей в качестве параметров. Ну и так далее, т.е что-то реализовать можно, но это будет не орм :)
🤝
N
классический орм как мне кажется на хранимках не сделать, ну представь что у тебя структура энтити будет зависеть от каких-то внешних параметров. так как хранимка в зависиомости от параметров может возвращать не только разные по содержанию датасеты но и вообще разные по структуре. дальше, Орм часто используют для веба и рест апи в котором есть PATCH, т.е обновление только нужных полей по указанному id объекта, на прямой работе с таблицей как это сделано у орм никаких проблем, но в хранимку то тебе надо передавать весь набор полей в качестве параметров. Ну и так далее, т.е что-то реализовать можно, но это будет не орм :)
именно поэтому я называю свою затею недоОРМ ))
ДП
в ормах это делается введением значения которое не мэппится в базу а вычисляется прямо в классе, ну т.е некое подобие вычисляемого поля
Боюсь это непроизводительно )
AZ
Боюсь это непроизводительно )
это еще мягко сказано :)