Здравствуйте, IB, Вы писали:

_>>Вот именно, что важна функциональность. И по ней, по своему предназначению, Redis — это СУБД. Не смотря на то, что некоторые ммм специалисты предпочитают использовать его в роли кэша (вместо специально предназначенных для этого инструментов). И разницу в этой функциональности понять очень легко: форумы работающие на Redis'е (без всяких других СУБД) существуют (и кстати летают), а форумов работающих на memcached не существует.
IB>Меня не покидает ощущение, что вы, коллега, придумали себе идеальную картину мира ориентируясь лишь на формальные наименования продуктов, и теперь с усердием достойным гораздо лучшего применения, пытаетесь подогнать окружающую действительность под ваши фантазии в одном отдельно взятом форуме...
IB>Увлекательно, но малопродуктивно.
IB>Так вот, те форумы, которые используют Redis и летают — используют Redis как раз в качестве распределенного кэша поверх классического SQL.


И где у нас тут https://github.com/NodeBB/NodeBB/tree/master/src/database "классический SQL"? )

Здравствуйте, _Case, Вы писали:

_C>Хорошо, а если рассмотреть следующую ситуацию — допустим пользователь по нажатию кнопки на сайте запускает некую сложную (не просто MERGE / UPDATE) процедуру пересчета данных за определенный период времени, например за месяц, алгоритм может использовать большое количество (десятки — сотни тысяч записей) из нескольких таблиц, если это реализовать хранимой процедурой (даже если в ней будут использоваться и курсоры и ещё что-то) — то будет просто запрос на базу вида: EXEC [ProcessDataForMonth] а если эту же задачу реализовывать средствами Entity Framework то придется сначала вытащить все эти сотни тысяч записей на BackEnd сервер, отпроцессать их, и затем сохранить снова в базу — это же займет больше времени чем сделать это всё на месте — внутри DB сервера, не гоняя данные по сети..

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

_C>Ещё пример — сложные отчеты, по моему опыту через ORM такой отчет (хотя бы 7-8 джойнов) будет строиться неприлично большое количество времени..

с nolock будешь селектить? или пускай весь мир подождет?

_C>Эта тема конечно о производительности EF, но процедуры я люблю именно за то что понятно что вызывается — запустил SQL профайлер и ясно какая страница что делает, а с потоком SQL-а от ORM так просто не разберешься..

А как потом удобно всю эту не тестируемую sql вермишель поддерживать и развивать...