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

G>Попробуем проанализировать причины.
G>С точки зрения языков общего назначения:
G>1) В реляционной алгебре (РА) есть проекция. Из-за нее количество типов, которыми оперирует РА, бесконечно. В статически типизированном языке любая попытка сгенерировать типы для работы с данными обречена на провал.

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

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

G>2) Можно генерировать типы ad-hoc, это делается в небольшом количестве языков на сегодня.

Только это вообще не нужно для данной задачи.

G>3) Нужно уметь в языке представлять операции РА и выражения над элементами кортежей. Если мы работаем с типами языка, то и выражения должны быть выражениями языка, а не dsl. По сути для полноценной реализации нужно цитирование.

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

G>4) Посчитаем мейнстрим-языки, которые умеют цитирование и ad-hoc типы. Я знаю C# и F# (он мейнстримый с натяжкой), оба умеют Linq.

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

G>5) А что если не генерировать типы и не использовать цитирование? Тогда мы получаем тяжеловесные ORM со всеми их недостатками, которые уже не раз написали в этой теме.

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

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

G>В итоге остается создать только новый язык, который будет лучше C# (в чем? сколько это будет стоить?). А потом продавить производителей СУБД чтобы они новый формат поддержали. Но тут проблема.

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

Хотя если посмотреть на текущую ситуацию с OpenGL (и соответствующим языком шейдеров) и Vulkan'ом (который пришёл на замену), то прослеживаются некоторые интересные аналогии. Если кто-то создаст нечто типа Vulkan'а (с таким же приростом производительности), только для СУБД, и его примут все основные производители (как произошло с вендорами видеочипов) то возможно что и побежит народ...

G>С точки зрения производителей БД:
G>6) Текстовый язык запросов на два порядка легче расширять, чем бинарный.
G>7) Используя SQL можно получить больше пользователей, чем любой другой язык запросов. Многие нереляционные субд используют sql-подобный язык.
G>8) Выгоды от использования нетекстового языка запросов — никакой. Парсинг запроса даже в 10кб текста занимает бесконечно малое время по сравнением со временем построения плана. А потом все движки этот план кешируют и повторно текст запроса даже не парсят.

Вроде про нетекстовый язык тут особо не говорили. Хотя могу тебе тут напомнить про BSON (бинарный JSON), используемый в MongoDB — можешь посмотреть на мотивы его появления. Но это отдельная тема для разговора, не имеющая особого отношения к утверждению об убогости SQL (его текстовость явно не входит даже в первую десятку минусов языка).

G>В итоге все, кто думает на два-три шага дальше, чем средний программист с завышенным ЧСВ, понимают что нет смысла устраивать революцию. Лучше спокойно допиливать средства с обоих стороны.
G>Например на волне хайпа с NoSQL взрослые движки впитали в себя полезные фичи, а языки обзавелись универсальными интерфейсами, с которыми можно и в монгу и в оракл сходить, используя по-максимуму фичи разных движков.

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