Просто стандартные EF и EF core стабильны, а вот как Plus версия в боевом проекте поведет себя дальше...вот это вопрос еще тот

это один большой костыль... непредвиденности там только с массовыми операциями - либа частично бесплатная и некоторые вещи требуют донат
при использовании этой либы в дополнение - проблем по миграциям пока не было обнаружено.. работаю чаще с PG - не знаю, как на других БД поведёт себя, но в теории - не должно быть ничего... к тому же это же просто прослойка для исполнения запросов - макет-то данных со связями ты делаешь на обычном ЕФ

Соблазняет фильтрация IncludeWhere , сладкая вещь)

да, там много сладких фишек - мне пришлось перейти на Z из-за бизнесовых новых связок - раньше БД использовалась на проекте чисто как справочник и всё было +/- независимым - там даппер в ПГ хоть 10к записей за миллисекунды засылал (ну обычный сиквел по-сути со стрингбилдером для массовых операций) - а как только добавились связи - не захотелось дальше сиквел насиловать...

Ну если что то критическое будет по скоростям, то придется вернуться к sql сырому)

Кстати, хотел поднять холиварный вопрос...)

естественно, но там уже самому придётся выпендриваться с проверками, есть ли такой гуид у связанной таблицы и прочее

Нормализация VS Денормализация -для сводных таблиц....Например сайт, где подобие соц.сети -и есть статистика -кол-во просмотров, комментов и т.д.

И вот когда нужно в превьюшках показать (top 25) сколько на каждой строке выборки (кол-во просмотров, комментов и т.д. )

Если например важна очень актуальность, без задержек(по подсчету этих полей)

(ща вот тут куча общих фраз, но они ИМХО отражают реальность)
тут только франкенштейна городить, если очень нужно быстродействие
опять же для твоего кейса нет серебряной пули - бенчмаркать и тюнить - только практика...
универсальных рекомендаций по нормализации/денормализации нет
(ну кроме очевидного - делай структуры данных как можно проще... а то вот у нас для бизнесовых менеджеров, когда хотелки оформляют - они бы любое поле сделали строкой, хотя зачастую там достаточно числовых типов, которые в памяти в разы меньше занимают места)

если делать на микросервисах, то я бы даже, возможно, разделил бы справочники и условную аналитическую инфу, которая льётся..

в частности, относительно недавно я узнал на практике про одну хорошую штуку - ClickHouse (он же кликхаус, он же КХ) - не реляционная БД от Яндекса (сначала скептически отнёсся) [не реклама]

Теперь на проекте дружно живут ПГ и КХ =)) в КХ льётся постоянная инфа (БД заточена на такое, когда у тебя рекорды просто валятся лавиной и тебе не требуется их править, всё это дело сжимается) - за месяц там десятки-сотни миллионов строк должны набегать... Так вот, если это дело хорошо оттюнить, то среди этих миллионов можно деть выборки за миллисекунды
- и реляционная часть данных не проседает т.к. ПГ не раздувается и быстро работает (тьфу-тьфу)

ммм....интересно

Надо ознакомится с этим решением Яндекс

Кстати, кто не работал с HangFire под .Net -очень советую

Спасибо!

у меня реально сначала такой скептицизм был... но когда я сравнил это дело с монгой... условно тестовый рекордсет ~25млн записей на монге занимает 1.2Гб, на КХ - тот же сет около 300Мб, да ещё и эта "сотона" по сравнению с монгой грепает записи в десятки раз быстрее, а в некоторых кейсах - в сотни... для меня это было таким открытием...

Спасибо за совет про clickhouse )) Читаю обзоры и очень пока нравится

ты только не забывай одну простую вещь - он не про редактирование и удаление - он про накопление и запросы... в чатах по КХ один умудрился забыть недавно про это и написал, что среди лярдов записей захотел удалить один рекорд - так эта хрень ему всю оперативу овер 64Гб на серваке сожрала и каких-то ошибок понакидала - там идёт переиндексация и переупаковка в таком кейсе и это пипец как хреново
так что это тоже не серебряная пуля - инструмент, который имеет свою область применения

ну так OLAP же)

Для статистических данных пойдет