В России опять напишут новый объектно-ориентированны - Компьютерные священные войны

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

_>А какое отношение этот всё имеет к SQL? Или ты относишь к нему t-sql, pl/sql, pl/pgsql и д.р. только потому, что там тоже есть буквы SQL? )))
Конечно. Мы же рассуждаем о RDBMS и том, что умеют они, а не о воображаемом языке, не существующем в природе.

S>>Опять какое-то передёргивание. Откуда взялось требование "эффективно задавать" что-то в клиентских языках? Клиентский язык является потребителем SQL.
_>Ээээ что? Клиентский язык в текущей реальности занят генерацией sql (с помощью склейки строк или чего-то более автоматизированного), который служит промежуточным языком между клиентским кодом и СУБД.
Не обязательно. Клиентский язык вызывает SQL. Например, он может вызывать хранимую процедуру, написанную заранее.
Лично я предпочитаю возможность генерации SQL кода на лету из языка высокого уровня, но это не обязательно. С ней (в практически интересных случаях) хорошо справляется linq2db.

_>Интересно, а что ты называешь сложной задачей? Наверное что-нибудь типа 10-и уровневого join'а и т.п. артефактов криворуких архитекторов? ) А как на твой взгляд задачка с простейшим фильтром по одной коллекции, но при этом отрабатывающая одновременно на десятках независимых узлов в сети — это сложная или нет? )))
Это — средней сложности. Вот мы посмотрели как плохо с ней справляется mongoDB — простейший фильтр по одной коллекции кладёт её на лопатки, заставляя просасывать терабайты через контроллер жёсткого диска.
Современный SQL на этой задаче уделывает монго-кластер, работая на ноутбучном процессоре от батарейки.
А когда объём хранилища превысит размеры ноутбукового винта и ёмкость 4U-сервера, SQL отмасштабируется на linked server и remote table partition прозрачно для клиентского приложения.
При этом каждый узел всё ещё будет выполнять быстрый поиск по индексу, получая примерно в 100 раз больший throughput, чем монга.
Прикол ещё и в том, что мы можем выполнять тот самый десятиуровневый джойн через все узлы, и получать все преимущества реляционной модели. А монга на этом джойне склеит ласты, увы.

_>Это у тебя какое-то искажённое восприятие реальности. Большинство noSQL СУБД появились на фоне модели MapReduce, предложенной в своё время Google. Т.к. SQL очевидно не имел (и до сих пор не имеет) возможности работы с подобными моделями, то от него пришлось отказаться. По сути это был вынужденный шаг (естественно люди предпочли бы работать с уже известным инструментом, если бы это было возможно), вследствие которого каждый стал придумывать что-то своё, а всё это множество совершенно разных СУБД стали называть noSQL.
Ну, может быть. Тем не менее, популярность noSQL получили не за mapReduce, а за то, что там типа думать не надо. Ах этот гадкий, гадкий SQL заставляет меня записывать все эти гадкие, гадкие схемы.
Ну да, я видел (например, вчера) реляционные БД, спроектированные как раз такими монго-стайл программистами.
Все индексы — строго одноколоночные. Зато по некоторым колонкам их по два.
Смотришь в хранимки — а там идут джойны по пяти-шести полям. И куча клееного SQL кода. Типа если параметр "менеджер" задан, то фильтруем по нему, а если не задан, то в колонку "клиент" выведем "менеджера". Вокруг этого — курсор, в нём бегаем по джойну из трёх таблиц (по пяти-шести полям в каждом случае), складываем всё во временную табличку, потом ещё из неё фильтр и группировка.
Явно получали странные результаты с задвоением строк, поэтому группировка по колонкам "композитного ключа", а все значения вынимаем через Max().

Вот, это как раз ровно наш случай. Эти ребята с большим бы облегчением пересели с pgsql на javascript, и думать бы забыли про все эти индексы и джойны.
Просто фигачили бы тупой процедурный код. А то, что он адски неэффективен — ну так он и сейчас адски неэффективен. Кого это беспокоит, когда через систему проходит пять-шесть заказов В МЕСЯЦ.
И платформа, которая весь этот ужос вызывает, много лет назад обучена работе с тормозными внешними системами; там встроенная асинхронность и повторные выполнения в случае сбоя.

Если бы то же самое клеил полноценный разработчик, то сделал бы в 100 раз более быстрое и в 10 раз более надёжное решение. И не из говна и соплей, а из нормальной модели.

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

_>>И не стоит втаскивать в этот конкретный вопрос (причём обсуждавшийся ещё и не с тобой) всю нашу с тобой обобщённую дискуссию, в которой действительно есть место неоднозначным суждениям и вкусовщине. А в данном конкретном вопросе IB высказал вполне однозначное и очевидно не верное утверждение. Что должно быть просто отмечено (если он конечно не пожелает упереться и попытаться доказать его, как изредка делают некие редкие неадекваты на этом форуме) и вычеркнуто из дискуссии.
S>Нет, Иван высказал вполне однозначное и очевидно верное утверждение.
S>А вот вы, коллега, передёргиваете. Иван отвечал на вопрос про for(). А вы лёгким движением руки превратили его в "произвольный императивный код".

О как интересно. Ну давай, расскажи, что же такое хитрое ты представил в своей голове, когда я говорил про "for()" (может строгий запрет на все остальные операторы языка или что?) и чем это твоё нечто принципиально отличается от произвольного императивного кода?

S>В такой жульнической постановке вопрос не имеет смысла — просто потому, что под капотом у linq (да и вообще у чего угодно) исполняется самый обычный императивный код.
S>Поэтому можно посмотреть на linq код, на выхлоп компилятора, и тупо среверсить его в "императивную форму". А если попутно удастся срезать пару углов за счёт тупости обычного JIT-а, то можно и обыграть linq.

Это вот ты сейчас по сути на 100% подтвердил моё мнение о бредовости того тезиза IB.

_>>Хы, все твои рассуждения тут базируются на том, что у нас имеется запрос вида "where id=123" или чуть сложнее, который естественно без проблем записывается на SQL и оптимизируется индексом.
S>Мои рассуждения базируются ровно на примере из документации Монги. Я не виноват, что они в своей документации приводят пример, на котором их обходит SQL сервер 10-летней давности.

Так, что-то меня утомили эти передёргивания. Давай определимся: при работе с sql 100% всех запросов работает только через индексы или же нет?

_>>Только вот совершенно непонятно, с чего это мы подобный запрос в MongoDB решили записать через функцию, а не через такой же find с индексом?
S>А по-моему совершенно понятно. "find c индексом" на монге потребует нетривиальных приседаний, и программист поленился. Примеров программистов, пишущих говнокод в SQL — миллионы. С чего это мы ожидаем, что они внезапно на Монге озаботятся производительностью и начнут продумывать индексы? Тем более, что монга беспощадна к тем, кто решил добавить индексы к большому объёму данных.

Ну т.е. в подходящем тебе условном соревнование должны участвовать говнокодер на MongoDB и профессионал на SQL, правильно? )))

_>>Очевидно же, что если у нас применена какая-то нетривиальная кастомная функция, то на SQL это вообще ещё надо будет умудриться суметь записать, а не про какие-то там индексы думать.
S>Я всё ещё жду монго-примера, на котором она выигрывает у SQL, а не наоборот.

Выиграет по какому параметру?

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

_>Вообще то прямо в этой темке уже был конкретный пример с доступом к предыдущим элементам.
С предыдущими элементами вроде разобрались же, Антон в соседней ветке наглядно показал, что если ограничения и есть, то не из-за языка, а по причине ограничений компилятора, который не достаточно сообразительный, хотя мог бы.

_> Если его мало, то можно ещё накидать — например поговорить о таких коллекциях как деревья и т.п. )))
А с деревьями вообще обратный эффект получился. Внезапно оказалось, что линк может работать одинаково эффекивно с любыми типами коллекций, а императивный код придется перепиливать каждый раз.

_>Ты видимо как-то странно прочитал мою фразу. )))
Ровно так как она была написана ))

_>Что ты здесь имеешь в виду? Код выполняемый на клиенте или на сервере?
Напомню, что ты утверждал, что причиной отсутствия толкового DSL-я для сиквельных баз были "ограничения" SQL. Я же имел ввиду, что любой DSL можно преобразовать в императивный код + SQL и собственно SQL тут не помеха. Императивная часть может выполняться как на клиенте, так и на сервере — не суть важно.
Здесь речь идет не о производительности, а о выразительности.

_>Ну так а ты этот C++ код передаёшь в СУБД внутри SQL запроса или как? )
А какая разница? Как ты передаешь этот код — это лишь детали синтаксиса. Выполняется он один фиг, только после того как движек базы отработал и выдал все записи.

_>Покажешь пример? Если ты конечно же не подразумеваешь под SQL (априори декларативным языком) какой-нибудь из процедурных языков с похожими названиями (типа pl/sql), как делают изредка неграмотные специалисты.
Хотя формально SQL не является полным по тьюрингу, единственное что его делает не полным, это ограничение на время выполнения запроса. Так что да, на SQL можно выразить все.
Но речь-то шла не об этом, ты там опять передернул. Речь шла о том, что необязательно выражать все именно в SQL-е, его вполне можно комбинировать с любым императивным языком.
Кстати, ограничивать только стандартом SQL в рамках нашего разговора, тоже не корректно. Мы всегда работаем с конкретной базой, и производители базы расширили SQL чтобы решать конкретные прикладные проблемы. Почему мы должны ограничивать себя не используя их наработки? Темболее, если мы сравниваем с той же монгой, которая вообще одно сплошное кастомное решение.

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

_>>TS — это замена JS? Хорошая шутка...

IT>А в чём проблема? Если ты про то, что TS всего лишь генерирует JS, то в своё время C++ тоже всего лишь генерировал C.

Только C++ тоже умеет генерировать JS — это означает, что он тоже заменой JS стал? )

_>>А вот WASM — это да, потенциально реальная замена. Но только тогда, когда будет реализован полноценный новый DOM API (это есть в планах, но где-то очень далеко, после SIMD, многопоточности и ещё много чего). А пока целевым применением WASM является только ускорение производительности для специфических задач типа кодеков, криптографии и т.п.
IT>Пока для WASM просто отсутствуют приличные средства разарбоатки. Но уже показали blazor и народ заинтересовался.

Для тех целей, для которых WASM позиционируется в данный момент (а не в светлом будущем), средства разработки вполне удобные. Что касается blazor, то он сейчас работает через ТАКИЕ костыли, что аж страшно становится.

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

IB>>Да что-то не очень прекрасно..
_>А что там не так https://db-engines.com/en/ranking_trend ?

Очередная тиоба? Всат.

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

_>Что касается blazor, то он сейчас работает через ТАКИЕ костыли, что аж страшно становится.

Вот только совершенно JSный реакт работает через точно такие же костыли.

S>Это — средней сложности. Вот мы посмотрели как плохо с ней справляется mongoDB — простейший фильтр по одной коллекции кладёт её на лопатки, заставляя просасывать терабайты через контроллер жёсткого диска.
S>Современный SQL на этой задаче уделывает монго-кластер, работая на ноутбучном процессоре от батарейки.
S>А когда объём хранилища превысит размеры ноутбукового винта и ёмкость 4U-сервера, SQL отмасштабируется на linked server и remote table partition прозрачно для клиентского приложения.
S>При этом каждый узел всё ещё будет выполнять быстрый поиск по индексу, получая примерно в 100 раз больший throughput, чем монга.
S>Прикол ещё и в том, что мы можем выполнять тот самый десятиуровневый джойн через все узлы, и получать все преимущества реляционной модели. А монга на этом джойне склеит ласты, увы.

не скажу за монгу, но при всем моем опыте с ораклом хадуп в виртуалке моего же десктопа прожевывает данные быстрее оракла. просто в бигдате 10 табличек не будет, будет одна, с денормализованным "документом". я играл с avro объектами в parquet файликах на hdfs. даже денормализованные паркетники у меня выходили меньше, чем датафайлы оракла. хотя я играл и с размером блока таблеспейсов и со слотами блокировок. parquet колончатый и упаковывает со словариком а потом еще и gzip.
дальше если речь о мапредюс он полнимает десяток мапперов и в терминах оракла многоблочным чтением, загружая все ядра. да, вычитает то он может и в разы больше, чем SQL, но и быстрее. на больших данных это очень заметно, ведь SQL джоин это или нестед луп долбящий одноблочным чтением или хеш-джоин, насилующий хдд еще и писаниной в TEMP хеша. но основная проблема — у SQL много меньше параллельности выходит. "linked server и remote table partition" — круто конечно, но это лицензия.

S>Ну, может быть. Тем не менее, популярность noSQL получили не за mapReduce, а за то, что там типа думать не надо. Ах этот гадкий, гадкий SQL заставляет меня записывать все эти гадкие, гадкие схемы.

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

Gt_

Здравствуйте, alex_public, Вы писали:
_>О как интересно. Ну давай, расскажи, что же такое хитрое ты представил в своей голове, когда я говорил про "for()" (может строгий запрет на все остальные операторы языка или что?) и чем это твоё нечто принципиально отличается от произвольного императивного кода?
Ничего хитрого я не представлял.
Я представлял ровно код, который пишет традиционный С++ программист — вот этот вот for() с итератором, вручную вынесенные "глобальные" переменные, которые используются на следующей итерации, и прочее.
Прикол-то в том, что linq программист просто добавит где-то там на этапе декларации коллекции индекс по атрибуту, и его код автоматически получит O(log(N)).
И сразу обгонит код на С++, который только что уделывал его по скорости в четыре раза.

_>Так, что-то меня утомили эти передёргивания. Давай определимся: при работе с sql 100% всех запросов работает только через индексы или же нет?
Нет конечно. Не все запросы работают через индексы. Вот тот, который приведён в примере Монги — работает.
Повторю в восьмой раз труднопонятную штуку: чтобы ускорить запрос на SQL, не обязательно переписывать сам запрос.
Можно немножечко подправить модель, и запрос продолжит работать.
Это — очень круто. Нет, это очень-очень круто.
А очень-очень круто это потому, что мы не меняем корректность кода. Единожды отлаженный код продолжает оставаться гарантированно корректным.
На С++ (и вообще на произвольном императивном языке) нам, вообще говоря, после "рефакторинга" нужно ещё доказывать эквивалентность исходного кода и нового кода.
Слово "рефакторинг" я взял в кавычки ровно потому, что обсуждаемые изменения — это нихрена не рефакторинг. Рефакторинг — это как раз такое изменение, которое не затрагивает семантику кода.
Введение временной переменной для выражения — рефакторинг. Выделение куска кода в метод — рефакторинг. Замена поиска по массиву на поиск по индексу — не, не рефакторинг.
И чем сложнее интересующий нас случай (тот самый десятиуровневый джойн), тем сложнее нам доказать, что изменение порядка траверсинга графа даёт те же результаты на исходных данных, что и до изменения.

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

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

_>>>Очевидно же, что если у нас применена какая-то нетривиальная кастомная функция, то на SQL это вообще ещё надо будет умудриться суметь записать, а не про какие-то там индексы думать.
S>>Я всё ещё жду монго-примера, на котором она выигрывает у SQL, а не наоборот.

_>Выиграет по какому параметру?
Например, по price/performance. Или хотя бы просто по performance, для начала.

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

S>А SQL проектировался для профессионалов

Это вряд ли. Оно изначально проектировалось для бухгалтеров всяких, поэтому у него такой идиотский синтаксис.

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

_>>Ну как же. Напомню, что в той нашей задачке происходила фильтрация по условию количества элементов внутренней коллекции в предыдущем элементе (который ты перевёл в текущий с помощью копирования). Т.е. при таком подходе у тебя на верхнем уровне получается не пара значений, а пара коллекций, которые ты соответственно обрабатываешь циклами.
S>А, я понял. Хочется наиграть на том, что мы типа итерируемся по коллекции, и сэкономить проход цикла. Ну, идея сама по себе интересная, хотя насколько драматичным будет выигрыш в производительности — вопрос открытый.
S>То есть понятно, что по факту linq проиграет, но не из-за семантики, а из-за того, что оптимизатор JIT-а сосёт.

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

S>А в том случае, если мы вычисляем одну и ту же f() от предыдущей и следующей коллекции, мы по-прежнему можем сэкономить на проходе цикла, сделав PairScan по результатам вычисления, а не по самой коллекции.

Конечно. Но если ты будешь вставлять условия фильтрации грубо говоря не в блоке where, а внутри некой своей дополнительной функции, генерирующей пары, то это будет по сути уже не linq, а тот же самый императивный код.

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

_>>И какой же? )
S>Ну тот же самый
S>

S>select MyAggregate(valueColumn) from PartitionedTable group by groupKey(....)
S>

S>Ничего военного map/reduce не делает.

Эм, я так понимаю, ты тут подразумеваешь, что мы ручками делаем подобные запросы на все сервера и потом так же ручками их объединяем? Да, и деление таблички у нас конечно же тоже руками, а не автоматическое, так? )

S>>>Самое прямое. Как только мы определили Custom Aggregate, мы можем его использовать в совершенно обычных, декларативных SQL Statements.
_>>Угу, но задать его в sql запросе ты не можешь.
S>Ну почему же не могу? Он же не сошествием священного огня в сервере заводится.
S>Нет никаких проблем добавить его прямо на лету, если нам вдруг понадобилось что-то такое, что нельзя было сформулировать на этапе развёртывания базы. Понадобится буквально две команды, чтобы он завёлся.
S>Потенциально ничего не мешает и определять этот кастом агрегат прямо на SQL, кроме нежелания писать компилятор.

Так "на лету" — это внутри запроса или же админом в консоли СУБД? )))

S>>>Ну, давайте предположим, что у нас есть классический Orders(id int identity, name varchar(max)) и OrderDetails(orderID int not null foreign key references orders(id), productID int not null foreign key references products, quantity int not null). Вот и вложенная коллекция.
_>>и?
S>Напишите тот код, который вам не очевидно, как сделать на SQL.

Собственно в чистом виде оно априори не повторяется в реляционной модели. Только с добавлением лишних сущностей (типа столбца id, задающего внешнюю коллекцию).

S>>>Ок, ждём примера кода.
_>>Какого? )
S>Какого-то нетривиального кода на Монге, где она пользуется "глобальной" переменной, и при этом работает корректно. А я попробую запустить аналог на моём ноуте на SQL Server Express 2017

Ну например тут https://docs.mongodb.com/manual/reference/operator/aggregation/redact/#pipe._S_redact есть примеры с переменными (правда системными, а не пользовательскими, но не суть).

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

_>>А какое отношение этот всё имеет к SQL? Или ты относишь к нему t-sql, pl/sql, pl/pgsql и д.р. только потому, что там тоже есть буквы SQL? )))
S>Конечно. Мы же рассуждаем о RDBMS и том, что умеют они, а не о воображаемом языке, не существующем в природе.

Стандарт на язык SQL оказывается уже воображаемый? )))

S>>>Опять какое-то передёргивание. Откуда взялось требование "эффективно задавать" что-то в клиентских языках? Клиентский язык является потребителем SQL.
_>>Ээээ что? Клиентский язык в текущей реальности занят генерацией sql (с помощью склейки строк или чего-то более автоматизированного), который служит промежуточным языком между клиентским кодом и СУБД.
S>Не обязательно. Клиентский язык вызывает SQL. Например, он может вызывать хранимую процедуру, написанную заранее.

Ещё раз: хранимые процедуры — это не SQL. Это процедурный (императивный) язык, в то время как SQL является полностью декларативным языком.

_>>Интересно, а что ты называешь сложной задачей? Наверное что-нибудь типа 10-и уровневого join'а и т.п. артефактов криворуких архитекторов? ) А как на твой взгляд задачка с простейшим фильтром по одной коллекции, но при этом отрабатывающая одновременно на десятках независимых узлов в сети — это сложная или нет? )))
S>Это — средней сложности. Вот мы посмотрели как плохо с ней справляется mongoDB — простейший фильтр по одной коллекции кладёт её на лопатки, заставляя просасывать терабайты через контроллер жёсткого диска.
S>Современный SQL на этой задаче уделывает монго-кластер, работая на ноутбучном процессоре от батарейки.
S>А когда объём хранилища превысит размеры ноутбукового винта и ёмкость 4U-сервера, SQL отмасштабируется на linked server и remote table partition прозрачно для клиентского приложения.
S>При этом каждый узел всё ещё будет выполнять быстрый поиск по индексу, получая примерно в 100 раз больший throughput, чем монга.
S>Прикол ещё и в том, что мы можем выполнять тот самый десятиуровневый джойн через все узлы, и получать все преимущества реляционной модели. А монга на этом джойне склеит ласты, увы.

Я что-то не понял, это вот ты сейчас реально пытаешься снова проводить сравнение между MongoDB запросом без индекса и SQL запросом с индексом? Ты серьёзно считаешь, что настолько убогая демагогия может пройти? )))

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

_>>Вообще то прямо в этой темке уже был конкретный пример с доступом к предыдущим элементам.
IB>С предыдущими элементами вроде разобрались же, Антон в соседней ветке наглядно показал, что если ограничения и есть, то не из-за языка, а по причине ограничений компилятора, который не достаточно сообразительный, хотя мог бы.

Мог бы инлайнить бесстековые сопрограммы? Что-то сомневаюсь... Но в любом случае я там же продемонстрировал, что возникает и алгоритмическая разница, для устранения которой компилятору дополнительно (т.е. это сработало бы только при условие работы инлайна) потребовалось теоретическое умение склейки двух одинаковых последовательных циклов в один.

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

Эмм, мы точно об одном и том же говорим? Ты считаешь, что работа с графами (дерево — это частный случай) может быть удобно реализована в рамках Linq? )))

_>>Что ты здесь имеешь в виду? Код выполняемый на клиенте или на сервере?
IB>Напомню, что ты утверждал, что причиной отсутствия толкового DSL-я для сиквельных баз были "ограничения" SQL. Я же имел ввиду, что любой DSL можно преобразовать в императивный код + SQL и собственно SQL тут не помеха. Императивная часть может выполняться как на клиенте, так и на сервере — не суть важно.
IB>Здесь речь идет не о производительности, а о выразительности.

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

_>>Ну так а ты этот C++ код передаёшь в СУБД внутри SQL запроса или как? )
IB>А какая разница? Как ты передаешь этот код — это лишь детали синтаксиса. Выполняется он один фиг, только после того как движек базы отработал и выдал все записи.

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

IB>Кстати, ограничивать только стандартом SQL в рамках нашего разговора, тоже не корректно. Мы всегда работаем с конкретной базой, и производители базы расширили SQL чтобы решать конкретные прикладные проблемы. Почему мы должны ограничивать себя не используя их наработки? Темболее, если мы сравниваем с той же монгой, которая вообще одно сплошное кастомное решение.

Ты только не путай расширения стандарта SQL (декларативного языка) в конкретной СУБД (ну например какие-нибудь конструкции типа connect by) и встроенный в большинство СУБД отдельный процедурный язык (у каждой свой).

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>А что там не так https://db-engines.com/en/ranking_trend ?
НС>Очередная тиоба? Всат.

С удовольствием буду использовать любую другую, более авторитетную и точную метрику сравнения. Покажешь где её искать?

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

_>>О как интересно. Ну давай, расскажи, что же такое хитрое ты представил в своей голове, когда я говорил про "for()" (может строгий запрет на все остальные операторы языка или что?) и чем это твоё нечто принципиально отличается от произвольного императивного кода?
S>Ничего хитрого я не представлял.
S>Я представлял ровно код, который пишет традиционный С++ программист — вот этот вот for() с итератором, вручную вынесенные "глобальные" переменные, которые используются на следующей итерации, и прочее.

Замечательно. Но ты так и не ответил на вопрос, чем это принципиально отличается от "произвольного императивного кода"?

Да, и кстати речь шла совсем не про C++, а про императивный код на том же C#. А что касается C++, то там есть свои средства работы с коллекциями (без ручного написания for), но работающие на совсем других принципах. Однако это уж точно совсем оффтопик в данной теме.

S>Прикол-то в том, что linq программист просто добавит где-то там на этапе декларации коллекции индекс по атрибуту, и его код автоматически получит O(log(N)).
S>И сразу обгонит код на С++, который только что уделывал его по скорости в четыре раза.

Ну так а программист с for просто потратит чуть больше времени на добавление индекса и опять же получит большее быстродействие.

_>>Так, что-то меня утомили эти передёргивания. Давай определимся: при работе с sql 100% всех запросов работает только через индексы или же нет?
S>Нет конечно. Не все запросы работают через индексы. Вот тот, который приведён в примере Монги — работает.
S>Повторю в восьмой раз труднопонятную штуку: чтобы ускорить запрос на SQL, не обязательно переписывать сам запрос.
S>Можно немножечко подправить модель, и запрос продолжит работать.
S>Это — очень круто. Нет, это очень-очень круто.
S>А очень-очень круто это потому, что мы не меняем корректность кода. Единожды отлаженный код продолжает оставаться гарантированно корректным.
S>На С++ (и вообще на произвольном императивном языке) нам, вообще говоря, после "рефакторинга" нужно ещё доказывать эквивалентность исходного кода и нового кода.
S>И чем сложнее интересующий нас случай (тот самый десятиуровневый джойн), тем сложнее нам доказать, что изменение порядка траверсинга графа даёт те же результаты на исходных данных, что и до изменения.
S>Могучесть декларативного стиля SQL — как раз в том, что мы можем тюнить индексы, партиционировать таблицы, и делать прочие улучшения, не боясь сломать поведение системы.

Это всё конечно правильно, для многих усреднённых случаев. Однако это не отменяет того факта, что данная логика перестаёт работать в двух случаях:
— в ряде не тривиальных задач, когда на sql/linq просто проблематично записать требуемое
— когда требуется максимально возможная производительность

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

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

Да, и кстати, SQL проектировался как раз не для профессионалов (не говоря уже о его текущем применение в виде промежуточного генерируемого языка), а для вообще людей не из IT. Как раз поэтому у него такой синтаксис, пытающийся походить на английский. Это кстати уже упоминалось в данной темке.

S>>>Я всё ещё жду монго-примера, на котором она выигрывает у SQL, а не наоборот.
_>>Выиграет по какому параметру?
S>Например, по price/performance. Или хотя бы просто по performance, для начала.

Ха, помнится ещё лет 5 назад прямо на этом форуме было подобное сравнение. И тогда mongo обошла sql server на каких-то рядовых (а не каких-то специальных или распределённых) запроса. Помню ещё тут были шокированные вопли типа "ну это нечестно, она же в памяти всё держит" и т.п. )))

	От:	alex_public
	Дата:	05.04.18 16:31
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	05.04.18 16:37
Оценка:	+2

	От:	alex_public
	Дата:	05.04.18 17:01
	Оценка:

От:	IB	http://rsdn.ru
Дата:	05.04.18 17:03
Оценка:

	От:	alex_public
	Дата:	05.04.18 17:25
	Оценка:

	От:	Ночной Смотрящий
	Дата:	05.04.18 17:29
	Оценка: