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

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

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

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

G>>2) Можно генерировать типы ad-hoc, это делается в небольшом количестве языков на сегодня.
_>Только это вообще не нужно для данной задачи.
Да ладно?
Есть таблица t а одной колонкой типа a, какой тип будет у проекции таблицы t, состоящей из (a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a...) ? Количество колонок может быть любое и не ограничено сверху разумными пределами.

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


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


G>>4) Посчитаем мейнстрим-языки, которые умеют цитирование и ad-hoc типы. Я знаю C# и F# (он мейнстримый с натяжкой), оба умеют Linq.
_>Тут подходят любые статические языки, имеющие элементы метапрограммирования, плюс большинство динамических языков. Т.е. в реальности выбор очень большой.
Да-да, назови хотя бы парочку (динамические не интересуют), ну чтобы можно было написать типа такого:

from x in t
where t.Category.Priority==1
select {
  StartDate =  x.StartDate.Date,
  EndDate = x.StartDate.Date + x.Duration / 24
}

Тут и проекция, и соединение, и выражения над элементами кортежа. И вообще говоря t не обязан быть ссылкой на таблицу, а может быть запросом.
Работа этого кода опирается на возможность цитирования и ad-hoc типы.
Покажи аналог на другом языке без ad-hoc типов или цитирования без потери типизированности или выразительности.



G>>5) А что если не генерировать типы и не использовать цитирование? Тогда мы получаем тяжеловесные ORM со всеми их недостатками, которые уже не раз написали в этой теме.
_>Всякие делают. И тяжеловесные, которые при этом удобно задают какие-то часто употребимые шаблоны работы в ущерб производительности. И быстрые (поэффективнее всяких там Linq, т.к. не требуют прогулок рефлексией по дереву), но при этом с близким к SQL синтаксисом (что для реальных задач не всегда удобно). Есть решения на любой вкус.
Про тяжеловесные не надо расказывать. Они — раковая опухоль всей индустрии последние 20 лет. Я уверен что нет других "паттернов" или "технологий" кроме ORM, которые потратили впуствую столько человеческого времени и машинных ресурсов. Помоему в майнинке крипты больше смысла, чем в использовании тяжеловесных ORM. А легковесные orm это не orm, а мапперы рекордсетов на объекты. Но они решают только одну проблему из многих при работе с данными. Причем не самую важную.



_>Правда не очень понятно зачем ты вообще об этом заговорил, т.к. все эти решения занимаются грубо говоря трансляцией кода некого языка в sql запрос, в то время как vdimas вроде как говорил о выкидывание самого sql из этой схемы. Правда я не очень вникал что он предложил на замену, но в любом случае все эти ORM и подобные им решения в таком случае будут не у дел.
Да, заметно что ты не вникал и мозг не включал.
Давай по порядку:
1) Чтобы выкинуть sql надо договориться о формате передачи запросов.
2) Вряд ли vdimas хочет чтобы он был текстовым, иначе вряд ли бы он этот разговор вообще затеял.
3) На стороне языка должно быть средство генерации запроса в бинарном виде, желательно на основе типов и выражений самого языка.
То есть для того кто пользуется orm или linq мало что изменится, но типа как "повысится эффективность".
Но эффективность по факту упирается не в текстовый SQL, а в средства языка по формулированию сложных запросов к базе и скорость дисков.



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


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

_>Вроде про нетекстовый язык тут особо не говорили. Хотя могу тебе тут напомнить про BSON (бинарный JSON), используемый в MongoDB — можешь посмотреть на мотивы его появления.
BSON появился потому что внутри монги хранить в JSON накладно. РСУБД такой чушью не занимаются.

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

_>Только после всего этого "не взрослые" nosql движки почему-то не пропали с горизонта, а продолжают вполне себе успешно теснить старые решения. Да, не во всех областях и возможно не такими мощными темпами, как во времена хайпа, но процесс вполне себе продолжается...
Да никто никого не теснил. А количество вакансий с указанием mongodb падает уже не первый год. NoSQL изначально были нишевыми продуктами\технологиями, а теперь их активно теснят РСУБД, которые научились фишкам NoSQL.