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

IT>>В полной мере, это невозможно в принципе. Только если кастрировать linq максимально, включая не только соответствующие причиндалы, но и ручки-ножки, и голову, т.е. всё, что торчит. Проблема в том, что linq выражения, являясь полноценным кодом в терминах самого приложения, могут включать в себя фрагменты, уникальные только для этого приложения, о которых СУБД не имеет понятия.

_>Так в этом и есть весь смысл. ))) И да, текущие реализации этого похоже не могут, но это не значит, что оно невозможно в принципе.

Мне сложно понять что ты там сам себе нафантазировал, но это именно что невозможно в принципе. Естественно, без вдумчивого кастрирования некоторых возможностей.

Gt_>> тем временем даже дата сайенс уходит от высокоуровневого SQL к гораздо более низкоуровневым R и python скриптам
IB>Вот тут сейчас теплое с мягким никто не попутал? Я тоже много умных слов знаю, но надо же их к месту употреблять ))
IB>Тпипчный стек технологий (и путь данных) в DS выглядит следующим образом:
IB>SOURCE -> STORE (вот тут SQL) -> CONVERT, TRANSFORM -> EXPLORE -> MODEL (вот здесь Python и R) -> VISUALISE -> PRODUCTION MANAGE (а здесь вообще, Java и C#)

раньше примерно так и было. а теперь они SOURCE обрабатывают не SQL, а R/Phyton скриптами. делают из raw data так называемые features и их уже скармливают ML фреймворку.

Gt_>>да, сильно влияет на дизайн. но и плюшки заметно масштабней мсскл с json. потому под эти сценарии майкрософт выкатила azure sql, а не мсскл с json.

НС>Azure SQL это и есть MSSQL, слегка подрихтованный. А для NoSQL там есть CosmosDB

хм ... может меня сбил с толку Azure SQL Data warehouse
https://social.technet.microsoft.com/wiki/contents/articles/40346.mpp-distribution-in-azure-sql-data-warehouse.aspx

там какое-то MPP

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

_>>Так никто не мешает повесить поверх низкоуровневого "ручного" подхода (с императивным кодом) ещё и удобный высокоуровневый интерфейсе. Причём это можно сделать абсолютно тривиально, добавив простейшую функцию вида generate_code_by_sql(). Которую кстати можно сделать как на клиенте (как хотел тут vdimas), так и на сервере (как реализовано уже прямо сейчас и неявно вызывается при каждом sql запросе).
_>>Вообще у нас тут несколько странная ситуация. В большинстве других областей программирования у нас всегда остаётся возможность добраться до низкого уровня. Т.е. развитие шло от некого базиса (исходящего от железа), до высокоуровневых абстракций. Но при этом доступ к низкому уровню всегда сохранялся. А в мире РСУБД у нас в качестве базиса используется уже весьма высокоуровневая абстракция, не позволяющая при надобности добираться до тонкой настройки (всяческие подсказки — это лишь жалкие костыли).
S>Прокомментирую вот этот вот момент, пропущенный в прошлый раз.
S>Во-первых, как справедливо заметил Иван, область применения "ручного привода" неуклонно снижается, по мере взросления индустрии. Вот, помнится, в ранних версиях С++ было ключевое слово register. Оно, возможно, и сейчас есть; но уже больше 20 лет оно никакой роли не играет — компилятор сам знает, какие переменные сложить в регистры, а какие оставить на стеке. То есть, "помогать" компилятору надо всё меньше и меньше.

Ты почему то не можешь увидеть принципиальную разницу между этой ситуацией и случаем с SQL. Уменьшение потребности обращения к низкому уровню не убирает его из цепочки, а всего лишь делает автоматически генерируемым для большинства случаев. И при необходимости (причём это может быть не только оптимизации, но и вообще написание нового языка) ты можешь в любой момент обратиться к этому низкому уровню. А в случае SQL у тебя нет этого низкого уровня в принципе — базовым API уже сложит высокоуровневый декларативный язык.

S>Во-вторых, этот "ручной привод" постепенно начинает мешать. Он мешает программисту: например, в СУБД я могу пойти и добавить или убрать индекс, будучи спокоен за корректность кода. В предлагаемом вами императивном случае изменение критерия сортировки массива нахрен сломает весь код, и это невозможно даже обнаружить без тщательного тестирования. Почему? Потому, что компилятор не в курсе о моём "ручном приводе", он не может мне помочь.

А ещё можно поделить в коде на ноль. А ещё можно просто дать команду форматирования диска. И что? Или может стоит убрать эту команду с компьютеров от греха подальше? )))

S>И компилятору "ручной привод" тоже мешает — скажем, если бы мы требовали буквального исполнения модификатора register, то компилятор был бы вынужден жертвовать производительностью в тех случаях, когда он "знает лучше".

В текущем стандарте C++ такого ключевого слова вообще то нет. ))) А вот различный "ручной привод" вполне имеется и используется.

S>Каждый раз, когда мы навязываем среде свой способ исполнения, мы связываем ей руки. "Ой, хозяин наверное умный, он лучше знает" — вынуждена думать среда. Ассемблерный код, оптимальный для 80386, будет нифига не оптимальным для Пентиума. Но раз программист написал на ассемблере — мы вынуждены делать то, что он написал.

Это слишком общая фраза, чтобы с ней можно было спорить или соглашаться. И кстати тех же C++ или SQL можно легко подвести под эту же мысль, только с другой стороны (сказать что они слишком низкоуровневые для определённых задач).

S>Хуже того — даже тот код, который написан на "высокоуровневом" интерфейсе рядом с "низкоуровневым", будет страдать.
S>Казалось бы — ну что там можно напороть в коде, который выполняет только чтение? Можно забыть применить нужные блокировки. Точнее, подумать, что "вот здесь они не нужны, потому что мне известно то, что не хранится в метаданных".
S>А завтра кто-то взял и применил этот код в другом месте — а чего? Вот у нас метод, который проверяет остатки на счетах. И вот у нас метод, который выполняет проводку — зачем нам дублировать код? Вызовем уже отлаженный метод проверки остатков. А послезавтра у нас изменились предположения, на основе которых мы делали оптимизацию, и в итоге в базу уезжает мусор. Иногда, но уезжает. И мы тратим месяцы на анализ race conditions, чтобы найти виновника — потому что каждый кусок кода выглядит полностью корректным. И даже почти всегда всё работает — косячит только под нагрузкой, и только когда данных много — то есть как раз тогда, когда хрен ты это отловишь в динамике.

И какое это всё имеет отношение, к обсуждаемой нами теме? )

S>Я бы хотел двигаться строго в противоположную сторону — чтобы движок видел весь код транзакции сразу, и сам выбирал стратегию удержания локов. Там, где нет повторных чтений — вот вам read committed, то есть отпускаем по мере чтения.
S>Там, где через строчку будет изменение — сразу захватываем update lock. Там, где мы перечитываем данные по многу раз — выполняем hold lock, т.е. делаем repeatable read.
S>В итоге у нас всё ещё гарантированная сериализуемость, но без снижения concurrency.

Почему бы и нет, особенно если сможешь ещё на сеть смаштабироваться. Возможно такое решение оказалось бы востребованным. И кстати, если бы современные СУБД имели низкоуровневый интерфейс, то ты бы возможно уже давно смог бы реализовать нечто подобное сам (при этом без потребности создания своей СУБД). Ну а в нашей реальности ты можешь только фантазировать (поверх SQL то такое не прикрутишь)...

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

Gt_>раньше примерно так и было. а теперь они SOURCE обрабатывают не SQL, а R/Phyton скриптами.
Чо, серьезно?
Если данные хранить не надо, то это не значит "уходит от SQL", это значит, что его там никогда не было.

Gt_>делают из raw data так называемые features и их уже скармливают ML фреймворку.
Прекрасно! ML фреймворк и есть вполне себе декларативный инструмент для аналитики данных. То есть в DS уже начали избавляться от тупой рутины. Сначала считали все в ручную, каждый сам велосипедил свою сетку на питоне в меру своего разумения, ручками выпиливая ее тип и параметры. Потом появились всякие tensorflow, куда вполне декларативным образом можно скормить обучающие и тестовые данные, а потом так же декларативно использовать полученную модель.
Спасибо за еще один пример очевидного тренда ))

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

S>>Я бы хотел двигаться строго в противоположную сторону — чтобы движок видел весь код транзакции сразу, и сам выбирал стратегию удержания локов. Там, где нет повторных чтений — вот вам read committed, то есть отпускаем по мере чтения.
S>>Там, где через строчку будет изменение — сразу захватываем update lock. Там, где мы перечитываем данные по многу раз — выполняем hold lock, т.е. делаем repeatable read.
S>>В итоге у нас всё ещё гарантированная сериализуемость, но без снижения concurrency.

_>Почему бы и нет, особенно если сможешь ещё на сеть смаштабироваться. Возможно такое решение оказалось бы востребованным. И кстати, если бы современные СУБД имели низкоуровневый интерфейс, то ты бы возможно уже давно смог бы реализовать нечто подобное сам (при этом без потребности создания своей СУБД). Ну а в нашей реальности ты можешь только фантазировать (поверх SQL то такое не прикрутишь)...
Как раз наоборот, благодаря декларативности SQL движок базы может поддержать и такой режим работы.
Более того, такие системы известны, называются SGT — Serialization Graph Testing. На практике себя зарекомендовали не очень хорошо, поэтому живых систем с таким режимом работы планировщика не встречается.

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

Gt_>да, сильно влияет на дизайн. но и плюшки заметно масштабней мсскл с json. потому под эти сценарии майкрософт выкатила azure sql, а не мсскл с json.
Как было сказано, Azure SQL — это и есть MSSQL. Который, помимо всего прочего, умеет MPP, columnstore indexes, in memory OLTP, R/Python и много чего другого.

Gt_>все та же идеология key-value, позволяющая обалденно масштабироваться, но уже явно проглядываются оракловые UNDO, REDO, оаркловое консистентное чтение ... скоро будет очень интересно.
key-value нет смысла использовать как основной источник данных, как раз из-за их ограничений, так что их удел — распределенный кэш и аналитика, в лучшем случае.

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

_>> Это я про общие положения. Но могу для разнообразия подкинуть ещё один примерчик для понимания. Простейшая, но очень нужная во многих областях задачка: имеем двухмерный массив чисел и надо получить из него новый массив, в котором каждая точка является средним от своих соседей (4-ёх или 8-ми, не суть). Что об этом скажет linq? )))
IB>Опять конкретный пример, решение для которого будет не сильно отличаться от решения для предыдушей задачки про пару значений, текущее и предыдущее.

Ну раз всё так просто, то можно увидеть код? )))

IB>Концептуальность-то в чем? Пока вы занимаетесь тем, что пытаетесь высосать примеры, которые были бы для linq-а не удобны (встречаемость таких примеров в реальной жизни — отдельный вопрос), но и примеры довольно странные и фундаментальную проблему линка что-то не получается сформулировать.

Хы, похоже кто-то у нас тут кроме SQL'я вообще ничего не видел. Вообще то подобная задачка встречается практические везде, где есть хоть какая-то обработка изображений или видео. Т.е. практически везде оно работает, причём частенько в реалтайме.

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

Если очень хочешь, то я могу даже сделать "подсказку" и показать императивную реализацию этого простейшего кода (аж целых 3 элементарные строчки) через два тех самых for'а....

_>>Ну это уже просто враньё.
IB>Вранье, то что это вранье ))

Ну кому интересно могут сами легко это проверить, пройдясь по сообщениям выше и убедившись в твоём вранье. )))

_>>Ну раз никакой ограниченности нет, то совершенно непонятно что же останавливает тебя в демонстрации решений озвученных простейших задачек.
IB>Раз ограниченность есть, то ничто не останавливает в том, чтобы ее сформулировать. Жду )

Я уже формулировал и не раз. Даже большое отдельное сообщение писал (не тебе) прямо на эту тему. Если ты не видел или не смог понять — это уже не мои сложности. А вот от тебя пока что ни строчки кода не было, а только пустая болтовня.

_>>Вот если появится хоть одно подобное решение, то тогда и будем говорить. А пока что это всё исключительно фантазии.
IB>Стоп-стоп. Вот сейчас опять, вопрос про одно, ответ про другое — про что удобно, а не про то что спрашивали.
IB>Здесь мы рассуждаем о гипотетической возможности и о том как мог бы выглядеть теоретически подобный язык. Причем тут реализация?

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

_>>>> Что уж тут говорить о поддержке наиболее активно развиваемых сейчас распределённых вычислений (СУБД на базе hadoop и т.п.), в которых уже даже MapReduce становится устаревшим (см. Spark).
IB>>>И в чем тут у linq-а проблема? как раз наоборот, в силу декларативности можно поддержать распределенные, параллельные, перпендикулярные и какие угодно вычисления, не оглядываясь на особенности реализации
_>>В том, что ты не сможешь использовать все возможности этих систем. Тебе будет доступно только грубо говоря их sql подмножество.
IB>Почему? В соседнем сообщении вы же сами пишите, что sql (а у нас даже не sql, а linq) — это более высокий уровень абстракции, и можно использовать хадуповские и другие map-reduce подобные низкоуровневые конструкции для получения нужного результата. Вы уж определитесь.

Эммм, ты вообще сам то понял, что написал? Или ты не в курсе самых базовых вещей в мире IT? Как раз чем инструмент более низкоуровневый, тем он более универсальный. Ты не можешь написать например драйвер ОС или что-нибудь подобное имя в рука только Питон. А вот на C++ ты можешь написать и драйвер и интерпретатор Питона. Причём нет никакого противостояния этих концепций — они отлично дружат между собой, дополняя друг друга до реально удобных решений. Никакой идеи "отмены низкоуровневого" нет. Так же как и идеи "писать всё на низкоуровневом". Ну и в мире СУБД надеюсь скоро будет такая же ситуация, в первую очередь благодаря nosql решениям. Этот процесс очень явно виден.

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

_>> То ты конечно же не испугаешься перейти к конкретному коду и его метрикам, не так ли?
IB>Нет, не испугаюсь, но не ощущяю необходимости. ))

Ну а мне кажется, что не ошущаешь способности это сделать. ))) Причём сразу в двух простейших задачках. В общем уже всё понятно с тобой: как доходим до кода или других реальных аргументов, так сразу мгновенный слив.

_>>Однако на то, чтобы написать очередную порцию неаргументированных лозунгов, приправленных понтами, у тебя время постоянно находится.
IB>Ну, во-первых не постоянно, во-вторых, не таких уж неаргументированных, а в третьих понты там можно найти только от собственных комплексов )))

Реальные аргументы от своих оппонентов я тут видел исключительно у Sinclair. С ним действительно интересно и полезно дискутировать, даже если в итоге каждый из нас останется при своём мнение. А беседа с тобой навевает только скуку (меня уже давно не привлекает возможность продемонстрировать слив своего оппонента, вместо этого интереснее спор со способным ответить что-то толковое).

Да, а понты от тебя в дискуссии с vdimas были такие, что аж смешно было читать (я тогда ещё даже не участвовал в дискуссии, но был на неё подписан).

_>>Вот смотри, в том же C++ компилятор уже давно научился создавать ассемблерный код эффективнее человека в большинстве случаев. Однако возможность встраивать произвольный ассемблерный код никто не убирает и она вполне себе используется в специфических случаях (например при работе с SIMD человек пока ещё частенько пишет более оптимальный код). Точно так же и с низкоуровневыми решениями из мира nosql. Поверх них легко можно накидать (и таких проектов есть множество, к большинству популярных nosql решений) высокоуровневый интерфейс в стиле SQL, покрывающий типовые задачи. Но при этом низкоуровневый доступ всё равно останется, позволяя легко реализовывать нестандартные или специально оптимизированные решения в нужных местах. А вот у классических РСУБД никакого низкоуровневого интерфейса что-то не видно, во всяком случае пока.
IB>Ну вот вы же сами прекрасно описали все тренды на примере C++ — количество ручного вмешательства постепенно уменьшается. То же самое будет происходить и с nosql, с теми, которые до этого доживут.
IB>Поэтому я совсем не улавливают логики в вашей аргументации, она скорее полностью подтверждает мой тезис.

Да, именно это будет с nosql. И это не имеет ничего общего с печальной ситуацией в мире SQL. Причём ты даже недооцениваешь скорость прогресса в такой ситуации. SQL-подобный интерфейс у того же hadoop не просто появится, а он уже есть и в нескольких разных вариантах. И каждый использует удобный ему вариант. А если кому-то не подойдёт ни один из существующих, то он элементарно напишет ещё один, свой. И всё это потому, что после появления этих интерфейсов никому не пришла в голову идея отрезать базовый api hadoop'а. Теперь надеюсь понятна мысль? )))

_>>Всё очень просто: это отсутствие вменяемого масштабирования на множество узлов у sql решений.
IB>У sql решений с масштабируемостью на множество узлов не то чтобы все идеально, но есть что предложить. Причиной появления nosql стало появление класса задач, для которых отказоустойчивость не нужна, зато важна скорость в виду обьшего объема данных. масштабируемость и параллельность это уже следствие.

"масштабируемость и параллельность это уже следствие." Так может ты способен предложить другое решение для обработки большого объёма данных? Нет? Тогда возможно это уже не просто следствие, а как раз целевое инженерное решение?

Да, кстати, а что ты называешь отказоустойчивостью? Что-то я подозреваю, что nosql решения, развёрнутые на множестве узлов с резервированиями (см на тот же гугл) дадут гораздо большую доступность сервиса, чем одинокий сервер с РСУБД. Или ты быть может называешь отказоустойчивостью что-то другое? )

_>>Вообще то этот подход (ключ-значение или ключ-документ или ключ-строка или даже ключ-функция — не суть) как раз и лежит в основе механизмов масштабирования на множество узлов.
IB>Да, но причем тут масштабирование?

Потому что именно ради него и реинкарнировали nosql решения.

Здравствуйте, alex_public, Вы писали:
IB>>Нет, не испугаюсь, но не ощущяю необходимости. ))

_>Ну а мне кажется, что не ошущаешь способности это сделать. ))) Причём сразу в двух простейших задачках. В общем уже всё понятно с тобой: как доходим до кода или других реальных аргументов, так сразу мгновенный слив.

Так ты же первый слился предоставить код, который из тебя Синклер выбивал пять постов подряд. В итоге, виляя задом в лучших традициях vdimаs'a, ты съехал с темы.

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

_>>Так в этом и есть весь смысл. ))) И да, текущие реализации этого похоже не могут, но это не значит, что оно невозможно в принципе.
IB>Как вы себе это в принципе представляете?
IB>Ну то есть, технически передать код приложения на сервер и даже выполнить его там, проблем действительно нет.

Даже с этим проблема. Представь, что у тебя в linq выражении в финальной проекции создаётся клинтский класс, который нерадивый девелопер завязал на какой-нибудь местный view model, которая в свою очередь имеет ссылку на UIWPF форму, где используются другие ресурсы всего приложения. Таким образом, чтобы это заработало на сервере нужно туда передавать не только код всего приложения, но и используемый им фреймворк, т.к. он может отличаться от серверного и вообще быть не установлен на сервере. Думаешь весь этот паровоз взлетит?

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

S>>Ну вот из описания монгодб возникает жосткое ощущение заката солнца вручную. Причём весь юмор — в том, что релизы монги последовательно приближают её к взрослой RDBMS как по функциональности, так и по производительности. Потому что чудес-то не бывает, и если мы коммитом называем коммит, то будь любезен сбегать в HDD и дождаться подтверждения. А пока мы коммитом называем то, что "в случае сбоя питания данные пропадут не более чем за 15 секунд", подвинуть RDBMS в OLTP никак не получится.
Gt_>по моему у монго идея атомарного сохранения документа, т.е. тот самый развесистый объект запихиваешь данные со всех таблиц рдбмс и получаешь в принципе годную во многих задачах схему. что касается сбегать на hdd — это не единственный вариант, всякие in memory grids предлагают дублировать транзакции по нодам и надеяться, что все копии разом не упадут. если узлы в разных датацетрах, вполне может прокатить схема.

На самом деле у Монго немного другая схема. Sinclair тут намекал на то, что в Mongo данные пишутся на диск не перед завершением транзакции, а с какой-то переодичностью (раз в сколько-то секунд, как раз для оптимизации быстродействия) и что типа только из-за этого она такая быстрая, но зато при сбое теряются данные, которые не успели быть записаны. Так вот на самом деле данные там пишутся как раз мгновенно (ну т.е. перед завершением транзакции), только не в саму БД, а в некий специальный журнал изменений (очищаемый как раз при записи в саму БД). Так что при сбое данные нормально будут жить на диске, и при новом запуске Монго спокойно прочитает журнал и добавит все нужные изменения в саму БД.

Ну во всяком случае так в ней работало несколько лет назад, когда я на неё смотрел. Думаю, что если сейчас что-то и изменилось, то только в лучшую сторону. )))

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

_>>- его реализацию всё же надо бы организовать без лишних рантаймовых накладных расходов
S>Ещё раз: нас интересует производительность, а не накладные расходы. Грубо говоря, вы выжимаете константу при O(N), а меня интересует переход к O(Log Log N).

Эм, какое ещё O(...), когда мы говорим о работе с нынешними СУБД (т.е. вся работа нашего кода заключается в генерации sql строк)?

_>>- если мы говорим о декларативном синтаксисе типа SQL, то он не кажется мне подходящим в качестве базового API к СУБД, в силу своей излишней высокоуровневости и как следствие ограниченности. Это не означает, что такой инструмент не нужен, просто если уж его делать, то как обёртку вокруг низкоуровневого API.
S>Это как раз потому, что вы не понимаете, что такое производительность. Чем сильнее мы зажимаем возможности языка, тем больше возможностей даём среде.

Конечно. И тем меньше возможностей оставляем пользователю языка. С учётом изначального предназначения SQL для бухгалтеров, его концепция выглядит вполне логичной и правильной. Однако воспринимать это как базовый инструмент для программистов — это уже совсем другое дело, весьма сомнительное.

S>Между прочим, лучшие оптимизаторы за последние 50 лет были у Фортрана — как раз из-за его убогой выразительности.

Вообще то Фортран как раз является вполне универсальным императивным языком. Так что мне вполне хватило бы его убогой выразительности в качестве базового языка для передачи запросов в СУБД. ))) Хотя в реальности было бы интереснее рассмотреть что-нибудь посовременнее, типа wasm.

_>>Ну в чём-то лучше, а в чём-то хуже (те же CTE с рекурсией).
S>Ну, пока что их реализация в linq2db выглядит вполне пристойно.

Какая ещё реализация? Судя по сообщениям в данной темке оно ещё только в разработке пока.

_>>Код, понятный и кстати весьма похожий на известные реализации (типа того же Spark). Только вот непонятно причём тут вообще Linq — оба представленных фрагмента являются классическим императивным кодом, только немного по разному структурированному.
S>При том, что мы будем использовать в linq выражениях агрегацию по вот такой функции, и она будет автоматически трансформироваться в server-side реализацию.

Это понятно и правильно. Непонятно зачем тут linq. )))

_>>Вообще то разница с рантаймовым МП очень большая, причём даже не в производительности, а в проверках на этапе разработки. Но Linq это не особо касается, т.к. там вообще странная схема. С одной стороны разбор происходит на этапе компиляции (это как бы плюс, т.к. позволяет проверки), а с другой МП там вообще не видно, т.к. превращение подготовленного компилятором AST в SQL — это уж точно не МП.
S>Странно. Многие считают, что выполнение T4 шаблонов по результатам database query — это МП.

Не очень понял про что ты. Но использование t4 для генерирования C# кода — это вполне себе МП (пусть и крайне убогое). Однако какое это имеет отношение к нашему вопросу?

_>>Это ты говоришь уже не об оптимизации под конкретные данные (как в PGO), которая обычно вероятностная, а скорее о каких-то фундаментальных свойствах данных (ну типа отсортированности или ограничений сверху/снизу и т.п.), которые вообще должны закладываться программистом на уровне алгоритма.
S>Нет. Всё наоборот: свойства должны закладываться на уровне данных, а алгоритм должен выбираться без участия программиста.

Он в любом случае задаётся программистом. ))) Просто в текущей ситуации с РСУБД этими программистами являются только создатели РСУБД, а программистам, использующим РСУБД, это недоступно. В отличие от популярных noslq решений, в которых это доступно всем.

S>Потому что программистов, способных корректно применить хороший алгоритм — примерно в 1000 раз меньше, чем программистов, способных сказать "список, отсортируйся по алфавиту".

Для слабых программистов тебе никто не мешает написать готовый фреймворк (собственно его даже писать с нуля не надо — можно просто скопировать основное из исходников текущих РСУБД), генерирующий нужный код для базовых случаев, задаваемых каким-то DSL.

_>>Вообще то мы тут говорили об уже не тривиальной коллекции (у которой в операторе [] заложена проверка) — с чего бы использовать в таком случае голый указатель, вместо своего типа итератора?
S>Вообще-то я говорил о минимальном типе "массив", и минимальном типе "указатель". Итератор — это вообще штука, у которой кроме оператора разыменования и инкремента может ничего и не быть.

Так, что-то ты запутался. В данном обсуждение ты критиковал отсутствие встроенной в язык проверки выхода за пределы массива. Я тебе сказал, что делать это на уровне языка ни к чему, а если очень хочется, то можешь легко создать свою коллекцию с проверками, встроенными в оператор []. На что ты начал говорить что тогда потеряется эквивалентность между операцией [] и работе с коллекцией через итератор. Что очевидно ошибочно, т.к. для нашей специальной коллекции с проверками никто не мешает написать точно такой же специальный итератор.

_>>Так iterator_type — это же параметр шаблона и соответственно для range созданного вокруг встроенного массива (int[]) это будет просто int*.
S>Вот тут я и не понимаю. В каком месте мы подставляем в шаблон этот параметр?

Так при создание range из двух итераторов он и подставляется. Кстати, на самом деле для коллекций так делать не обязательно (т.е. внутри оно так и происходит, но писать этот код руками не надо — range умеет инициироваться по любой коллекции сам), я просто хотел продемонстрировать самый низкий уровень и универсальность подхода (итератор то может быть любым).

_>>Смысл range? Как раз для того, чтобы удобным образом записывать различные операции с массивами (компоновать конвейер операций из элементарных). Приблизительно тоже самое, чем занимается Linq в реализации через IEnumerable, только удобнее (нет никаких проблем с заданием того же двоичного поиска), универсальнее (тот же произвольный доступ по коллекции спокойно работает) и эффективнее (никаких накладных расходов).
S>Ох-хох-хоо. Если бы авторы FCL хотели дать пользователям возможность стрелять себе в ноги, то никакой проблемы с заданием того же двоичного поиска бы и не было.
S>Точнее, их и так уже нет — вот вам BinarySearch: https://msdn.microsoft.com/en-us/library/system.array.binarysearch(v=vs.110).aspx, вот вам ArraySegment: https://msdn.microsoft.com/en-us/library/1hsbd92d(v=vs.110).aspx.
S>Extension Method для BinarySearch поверх ArraySegment пишется в две строки, после чего все вот эти вот цепочки upperBound и прочего пишутся на C# без напряжения.

Вот не стоит передёргивать мои слова. Я нигде не говорил, что у C# есть какие-то проблемы с написанием подобного кода. Как раз наоборот, на C#, как на полноценном императивном языке, все описанные проблемные примеры легко реализуются (через банальный for и т.п., который уже даже может быть написан и находиться в библиотеке как готовая функция). Речь шла о неспособности решать эти задачи именно на Linq.

_>>У кого O(N) в твоём примере я вижу. А у кого O(1) не вижу. Собственно я вообще не вижу в твоём примере никого кроме одной странной коллекции, так что совершенно не понятно кого с кем и для чего ты сравниваешь.
S>В том-то и дело — оверхеда нет, а толку — чуть. Из этого мы делаем вывод, что полезность гонки за "отсутствием оверхеда" сильно преувеличена.
S>Надо гнаться не за оверхедом, а за производительностью. В частности, если у меня есть код, который тратит "лишнее" время на анализ предусловий, зато после этого выполняется за O(1), то мне неинтересен код с O(N^2), даже если в нём "оверхеда" строго ноль.

Ну а можно писать код, который будет выполняться за O(1) и без анализа предусловий. )

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

Gt_>> тем временем даже дата сайенс уходит от высокоуровневого SQL к гораздо более низкоуровневым R и python скриптам
IB>Вот тут сейчас теплое с мягким никто не попутал? Я тоже много умных слов знаю, но надо же их к месту употреблять ))
IB>Тпипчный стек технологий (и путь данных) в DS выглядит следующим образом:
IB>SOURCE -> STORE (вот тут SQL) -> CONVERT, TRANSFORM -> EXPLORE -> MODEL (вот здесь Python и R) -> VISUALISE -> PRODUCTION MANAGE (а здесь вообще, Java и C#)



А ты вообще в курсе что такое Jupyter Notebook, как он работает и какое место занимает в современном мире DS? )))

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

_>>Так в этом и есть весь смысл. ))) И да, текущие реализации этого похоже не могут, но это не значит, что оно невозможно в принципе.
IT>Мне сложно понять что ты там сам себе нафантазировал, но это именно что невозможно в принципе. Естественно, без вдумчивого кастрирования некоторых возможностей.

Я в начале не понял о чём таком невозможном ты писал. И только прочитав это http://rsdn.org/forum/flame.comp/7142135.1

Автор: IT
Дата: 11.05.18

увидел в каком странном направление свернул ход твоих мыслей. Может ты пояснишь с помощью какой логической цепочки ты дошёл до такого?

Значит изначально мы обсуждали вопрос, как бы покрасивее заставить выполняться наш произвольный код (задаваемый клиентом) на сервере (в данном случае РСУБД). И смотрели можно ли приспособить к этому Linq в текущей или некой гипотетической реализации. Теперь поясни, откуда взялась мысль о том, что кому-то понадобится передавать серверу на выполнение код GUI? Или ты имел в виду, что это произойдёт как-то не специально? Ну очевидно же, что если уж делать такую реализацию через Linq, то предназначенный для исполнения на сервере код должен быть чётко обособлен от всего остального кода, иначе как компилятор поймёт что исполнять на клиенте, а что отсылать на сервер?

Ну а если уж кто-то захочет сознательно передать на исполнение серверу некий GUI код со всем его фреймворком, то это уже очевидно его проблемы — программистские инструменты не обязаны поддерживать полных дебилов. )))

P.S. Что касается реальности реализации в принципе, то вот тот же IB писал пару сообщений назад:

Даже если отбросить сомнительную пользу этого подхода, то нет никаких проблем запихнуть в выражение произвольную (императивную) лямбду и даже попробовать поддержать ее на стороне сервера.

Ну лично у меня есть сомнения в том, что "нет никаких проблем"... ))) Однако если постараться (на уровне языка и компилятора, т.е. не с текущей реализацией Linq), то думаю вполне реально.

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


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, если вы их знаете, озвучите (или процитируйте) пожалуйста...

_>На самом деле у Монго немного другая схема. Sinclair тут намекал на то, что в Mongo данные пишутся на диск не перед завершением транзакции, а с какой-то переодичностью (раз в сколько-то секунд, как раз для оптимизации быстродействия) и что типа только из-за этого она такая быстрая, но зато при сбое теряются данные, которые не успели быть записаны. Так вот на самом деле данные там пишутся как раз мгновенно (ну т.е. перед завершением транзакции), только не в саму БД, а в некий специальный журнал изменений (очищаемый как раз при записи в саму БД). Так что при сбое данные нормально будут жить на диске, и при новом запуске Монго спокойно прочитает журнал и добавит все нужные изменения в саму БД.

_>Ну во всяком случае так в ней работало несколько лет назад, когда я на неё смотрел. Думаю, что если сейчас что-то и изменилось, то только в лучшую сторону. )))

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

Gt_

Gt_>>раньше примерно так и было. а теперь они SOURCE обрабатывают не SQL, а R/Phyton скриптами.
IB>Чо, серьезно?
IB>Если данные хранить не надо, то это не значит "уходит от SQL", это значит, что его там никогда не было.

серьезно. и опыт реальный имеется. раньше было модно подготавливать данные чем-то высокоуровневым типа sas data miner, который транслировал свои flow в sql. теперь мода на гораздо более низкоуровневые R/Phyton

Gt_>>делают из raw data так называемые features и их уже скармливают ML фреймворку.
IB>Прекрасно! ML фреймворк и есть вполне себе декларативный инструмент для аналитики данных. То есть в DS уже начали избавляться от тупой рутины. Сначала считали все в ручную, каждый сам велосипедил свою сетку на питоне в меру своего разумения, ручками выпиливая ее тип и параметры. Потом появились всякие tensorflow, куда вполне декларативным образом можно скормить обучающие и тестовые данные, а потом так же декларативно использовать полученную модель.
IB>Спасибо за еще один пример очевидного тренда ))

вообше не понял о чем тут речь. я говорю о том, что у аналитиков мода в подготовке данных ушла от sql к всяким датафреймам из R/Phyton. ML фреймворк это уже следующий этап, но и там я уже не вижу ничего декларативного.
https://www.tensorflow.org/programmers_guide/low_level_intro — ничего декларативного не проглядывается. spark ML практически так же выглядит.

Gt_

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

_>Значит изначально мы обсуждали вопрос, как бы покрасивее заставить выполняться наш произвольный код (задаваемый клиентом) на сервере (в данном случае РСУБД). И смотрели можно ли приспособить к этому Linq в текущей или некой гипотетической реализации.

И я тебе сразу объясняю как ведущий сабаковод в этом деле. Приспособить к этому Linq без существенной кастрации его возможностей нельзя. Какое слово из этого предложения тебе не понятно?

_>Теперь поясни, откуда взялась мысль о том, что кому-то понадобится передавать серверу на выполнение код GUI?

Это то, что ты в результате получишь. Точнее ты это даже не получишь. Ты об это элементарно обламаешься.

_> Или ты имел в виду, что это произойдёт как-то не специально? Ну очевидно же, что если уж делать такую реализацию через Linq, то предназначенный для исполнения на сервере код должен быть чётко обособлен от всего остального кода, иначе как компилятор поймёт что исполнять на клиенте, а что отсылать на сервер?

В случае Linq компилятор вообще ничего не поймёт. Ещё раз, для этого нужно будет либо заранее вводить массу ограничений, либо научить компилятор вместе с клиентским кодом заглядывать в код сервера.

_>Ну а если уж кто-то захочет сознательно передать на исполнение серверу некий GUI код со всем его фреймворком, то это уже очевидно его проблемы — программистские инструменты не обязаны поддерживать полных дебилов. )))

Я бы сформулировал это по другому — программисты не обязаны использовать инструменты, созданные полными дебилами.

_>Ну лично у меня есть сомнения в том, что "нет никаких проблем"... ))) Однако если постараться (на уровне языка и компилятора, т.е. не с текущей реализацией Linq), то думаю вполне реально.

Советую сразу поработать над составлением списка ограничений. А затем убедиться в том, что твой кастрат будет проигрывать даже текущей реализации Linq.

_>>MapReduce очевидно не является разновидностью sql. ))) Более того, все эти императивные подходы очевидно являются более низкоуровневыми, чем декларативный подход sql. И соответственно можно относительно не сложно реализовать SQL интерфейс поверх того же Hadoop или Spark (и такие проекты есть), но не выйдет сделать обратное.
MH>MapReduce это больше про как выполнять. а sql про как описать. MapReduce выражается через sql — упрощенно это select и group by.
MH>и я бы не назвал MapReduce "императивным" подходом.

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

Gt_