Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, kov_serg, Вы писали:
_>>Будущий язык будет обеспечивать в процессе работы модули безопасности и контролируемый доступ к данным.
_>>Поддержка сорм из каропки это замечательно.
V>Справедливости ради, удобный язык для удалённого доступа к данным напрашивается уже слишком давно.
V>Потому что SQL безбожно устарел и вообще в современной разработке является сущностью второго рода — производной генерируемой хренью/абракадаброй. 
Ооо, как я мог пропустить очередной срачЪ на тему "SQL против людей которые считают себя умнее других"...
Причем не от кого-то, а от человека с самым высоким ЧСВ и самой низкой квалификацией на форуме.
Похоже ты открыл для себя работу с СУБД на этот раз...
Люди пользуются SQL добрых 30 лет (+\-) и никто (реально НИКТО) не изобрел ничего лучше. Как думаешь почему?
Попробуем проанализировать причины.
С точки зрения языков общего назначения:
1) В реляционной алгебре (РА) есть проекция. Из-за нее количество типов, которыми оперирует РА, бесконечно. В статически типизированном языке любая попытка сгенерировать типы для работы с данными обречена на провал.
2) Можно генерировать типы ad-hoc, это делается в небольшом количестве языков на сегодня.
3) Нужно уметь в языке представлять операции РА и выражения над элементами кортежей. Если мы работаем с типами языка, то и выражения должны быть выражениями языка, а не dsl. По сути для полноценной реализации нужно цитирование.
4) Посчитаем мейнстрим-языки, которые умеют цитирование и ad-hoc типы. Я знаю C# и F# (он мейнстримый с натяжкой), оба умеют Linq.
5) А что если не генерировать типы и не использовать цитирование? Тогда мы получаем тяжеловесные ORM со всеми их недостатками, которые уже не раз написали в этой теме.
В итоге остается создать только новый язык, который будет лучше C# (в чем? сколько это будет стоить?). А потом продавить производителей СУБД чтобы они новый формат поддержали. Но тут проблема.
С точки зрения производителей БД:
6) Текстовый язык запросов на два порядка легче расширять, чем бинарный.
7) Используя SQL можно получить больше пользователей, чем любой другой язык запросов. Многие нереляционные субд используют sql-подобный язык.
8) Выгоды от использования нетекстового языка запросов — никакой. Парсинг запроса даже в 10кб текста занимает бесконечно малое время по сравнением со временем построения плана. А потом все движки этот план кешируют и повторно текст запроса даже не парсят.
В итоге все, кто думает на два-три шага дальше, чем средний программист с завышенным ЧСВ, понимают что нет смысла устраивать революцию. Лучше спокойно допиливать средства с обоих стороны.
Например на волне хайпа с NoSQL взрослые движки впитали в себя полезные фичи, а языки обзавелись универсальными интерфейсами, с которыми можно и в монгу и в оракл сходить, используя по-максимуму фичи разных движков.
