MH>>да, РСУБД в рамках своей реализации sql поддерживают императивные возможности, но когда дело доходит до декларации/выполнения запроса к данным (именно sql) — сам запрос остается чисто функциональным (или может термин декларативный — тут больше подойдёт). MH>>но и linq ведь сделан в рамках языка общего назначения, а значит при построении linq-запросов, итерации по результатам можно использовать императивные приёмы, причём возможностей будет заметно больше. будет разница в том, что в 1-м случае это выполняется на сервере СУБД, во 2-м — на клиенте, но это IMHO не концептуальный недостаток, просто стоит учитывать.
_>Если linq научится отправлять прямо свой код (включая пользовательские лямбды) для выполнения на сервер, то это будет уже совсем другая история. Но это опять же будет возможно только при появление у СУБД какого-то иного интерфейса, помимо SQL. О чём собственно и была изначальная дискуссия.
дак linq уже умеет отправлять пользовательские лямбды (не любые конечно) на сервер. например подобная : .Where(x=> x.Name.StartsWith("И") && x.Name.Length>=5)
целиком будет выполнено на сервере.
_>MapReduce очевидно не является разновидностью sql. ))) Более того, все эти императивные подходы очевидно являются более низкоуровневыми, чем декларативный подход sql. И соответственно можно относительно не сложно реализовать SQL интерфейс поверх того же Hadoop или Spark (и такие проекты есть), но не выйдет сделать обратное.
MapReduce это больше про как выполнять. а sql про как описать. MapReduce выражается через sql — упрощенно это select и group by.
и я бы не назвал MapReduce "императивным" подходом.
_>>>Linq автоматически наследует все концептуальные проблемы SQL. MH>>ну раз уж упомянули про "концептуальные проблемы SQL", то было бы интересно услышать ваше видение их...
_>Эм, вроде как вся данная дискуссия про это. И я высказывался по этому вопросу уже не раз. )
возможно где-то это и есть, но вдумчиво прочитать всю дискуссию думаю мало кто осилит, тк большая её часть составляет упражнения участников в риторике.
по крайне мере я не смог, и не увидел нигде конкретных четко сформулированных концептуальных проблем SQL, если вы их знаете, озвучите (или процитируйте) пожалуйста...
