TN
не вышло с монго )) кто нить поможет правильно запросс составить с lookup?
Size: a a a
2021 June 22
IV
Ну вдруг ему так хочется
IV
Мне непонятно какая альтернатива репозиторию? Юзать сразу в BLL DBCONTEXT? Или хреначитб 100500 классов-стореджей, которые принимают контекст и имплементируют тупо crud
Ɖ
Можно спросить архитектора с 15 летним опытом
IV
Ну только если у него кофе-брейк и готов меня читать)
IV
@euroUK pls answer
Ɖ
Ну мой гитхаб во время кофе брейка он ревьювил
Ɖ
Думаю тебя он признает тоже
AW
можно и даже лучше сделать листы и чтоб еф сделал +5 табличек many-to-many и это будет надежнее но данные у меня там будут очень редко меняться а при запросах оно бы джоинило дофига таблиц а такие запросы будут часто, и думаю это будет лишняя нагрузка, хотя джойн вроде лучше чем 5 запросов, может еще поменяю
Ɖ
Тогда надо архитектуру слегка менять
Ɖ
Сделать вьюху или таблицу которая будет иметь агрегированные данные и они будут пересчитываться при обновлении связанных данных
Ɖ
Но это если заморочиться хочется (и если надо)
Ɖ
Таким образом можно добиться мгновенного получения этих агрегированных данных. но тут есть пара своих недостатков
Ɖ
Тем более если меняется оно редко. подход который я ниже описал подойдет идеально, ибо не будет ситуации когда данные в базе обновились (основные) а агрегация не успела еще
И тогда данные в агрегации были бы неактуальные какое то время
И тогда данные в агрегации были бы неактуальные какое то время
Ɖ
Я забыл как он по уму называется
AW
это реализщуемо в EF?
Ɖ
Делается не на уровне EF
Ɖ
EF это DAL в твоем приложении. тебе надо в тот момент когда ты обновляешь связанные данные каким то образом сообщать сервису или куску твоего кода который отвечает за обновление агрегации типо "пора пересчитать" и этот код будет делать агрегацию и прочее
Ɖ
В некоторых СУБД это можно сделать прям на уровне базы
Ɖ
Сделать хранимку которая будет триггерится по триггеру обновления базы