Здравствуйте, MadHuman, Вы писали:
_>> Более того, используемая для работы с коллекциями реализация (IEnumerable) является даже более ограниченной (только последовательный доступ), чем классический SQL, для которого в СУБД происходит интерпретация в императивный код. MH>это ещё более спорное утверждение (если рассматривать linq именно как средство для работы с РСУБД). в linq реализация IEnumerable не используется. упрощённо можно считать, что IEnumerable<T> интерпретируется как источник данных (записей класса T), таблица например.
Вроде как ясно написано же, что в данном пункте речь идёт о работе с коллекциями (т.е. чем-то типа int[]), а не с РСУБД.
MH>да, РСУБД в рамках своей реализации sql поддерживают императивные возможности, но когда дело доходит до декларации/выполнения запроса к данным (именно sql) — сам запрос остается чисто функциональным (или может термин декларативный — тут больше подойдёт). MH>но и linq ведь сделан в рамках языка общего назначения, а значит при построении linq-запросов, итерации по результатам можно использовать императивные приёмы, причём возможностей будет заметно больше. будет разница в том, что в 1-м случае это выполняется на сервере СУБД, во 2-м — на клиенте, но это IMHO не концептуальный недостаток, просто стоит учитывать.
Если linq научится отправлять прямо свой код (включая пользовательские лямбды) для выполнения на сервер, то это будет уже совсем другая история. Но это опять же будет возможно только при появление у СУБД какого-то иного интерфейса, помимо SQL. О чём собственно и была изначальная дискуссия.
_>>Что уж тут говорить о поддержке наиболее активно развиваемых сейчас распределённых вычислений (СУБД на базе hadoop и т.п.), в которых уже даже MapReduce становится устаревшим (см. Spark). MH>разве там используется какая-то другая концептуальная модель работы с данными, и не разновидность sql? MH>полагаю что не другая, а значит это будет лиш вопрос реализации linq-провайдера к этой базе.
MapReduce очевидно не является разновидностью sql. ))) Более того, все эти императивные подходы очевидно являются более низкоуровневыми, чем декларативный подход sql. И соответственно можно относительно не сложно реализовать SQL интерфейс поверх того же Hadoop или Spark (и такие проекты есть), но не выйдет сделать обратное.
_>>Linq автоматически наследует все концептуальные проблемы SQL. MH>ну раз уж упомянули про "концептуальные проблемы SQL", то было бы интересно услышать ваше видение их...
Эм, вроде как вся данная дискуссия про это. И я высказывался по этому вопросу уже не раз. )
