А я котика в SQL нарисовал (не ASCII-art!)

[oleg lebedev]

Поведайте нам, что вы можете предложить вместо SQL чтобы было понятно чтовы ещё знаете.

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

Я ничего не знаю про то что вы тут написали, но если это лучше чем SQL во всех отношениях, почему это всё не вытеснило этот "уродливый код"? Каково ваше мнение, как эксперта использования "Рельяционной алгебры" и "аналога темплетов"? Наверное, засилие бухгалтеров в индустрии мешает инновационным технологиям.

Дмитрий написал, старый язык с грузом совместимости.

Для старого кода я бы ещё понял, но ведь legacy кодом далеко не всё ограничивается. Если, что-то лучше чем SQL есть в наличии, почему на ваш взгляд, он не поддерживается современными DB по крайней мере основной массой.
Вот возьмите postgres. Это идеальная платформа для внедрения чего-то лучше чем есть. Почему там то, что вы считаете лучше чем SQL неподдерживается?
В postgres можно было внедрить как одну из многих опций для написания функций. В данный момент там поддерживается и sql, и plsql, и perl, и python, c и кажется ещё что-то.
Если бы что-то было лучше чем существующие опции, то уже нашлись бы энтузиасты, кто это бы внедрил. Я хочу подчеркнуть "лучше" хотя бы по одному критерию, а не просто другое.
Ваше мнение хотелось бы услышать.
То что кто-то что-то выдумал другое - ещё далеко недостаточно для принятия в производственную сферу. Нужны преимущества понятные для какой-то весомой части специалистов в этой области.

[OtherSide]

Поведайте нам, что вы можете предложить вместо SQL чтобы было понятно чтовы ещё знаете.

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

Я ничего не знаю про то что вы тут написали, но если это лучше чем SQL во всех отношениях, почему это всё не вытеснило этот "уродливый код"? Каково ваше мнение, как эксперта использования "Рельяционной алгебры" и "аналога темплетов"? Наверное, засилие бухгалтеров в индустрии мешает инновационным технологиям.

Дмитрий написал, старый язык с грузом совместимости.

Для старого кода я бы ещё понял, но ведь legacy кодом далеко не всё ограничивается. Если, что-то лучше чем SQL есть в наличии, почему на ваш взгляд, он не поддерживается современными DB по крайней мере основной массой.
Вот возьмите postgres. Это идеальная платформа для внедрения чего-то лучше чем есть. Почему там то, что вы считаете лучше чем SQL неподдерживается?
В postgres можно было внедрить как одну из многих опций для написания функций. В данный момент там поддерживается и sql, и plsql, и perl, и python, c и кажется ещё что-то.
Если бы что-то было лучше чем существующие опции, то уже нашлись бы энтузиасты, кто это бы внедрил. Я хочу подчеркнуть "лучше" хотя бы по одному критерию, а не просто другое.
Ваше мнение хотелось бы услышать.
То что кто-то что-то выдумал другое - ещё далеко недостаточно для принятия в производственную сферу. Нужны преимущества понятные для какой-то весомой части специалистов в этой области.

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

[Palych]

В postgres можно было внедрить как одну из многих опций для написания функций. В данный момент там поддерживается и sql, и plsql, и perl, и python, c и кажется ещё что-то.

кстати, а они предоставляют API для доступа к данным помимо SQL?
Или можно работать только с результатами SQL запросов?

[oleg lebedev]

В postgres можно было внедрить как одну из многих опций для написания функций. В данный момент там поддерживается и sql, и plsql, и perl, и python, c и кажется ещё что-то.

кстати, а они предоставляют API для доступа к данным помимо SQL?
Или можно работать только с результатами SQL запросов?

Разработчики ( developer community) предоставляют исходный код с возможностью создания всякого рода extensions. Поддержка разных языков программирования осуществляется через extensions. Например Python через extension "plpythonu"
https://www.postgresql.org/docs/9.5/sta ... ython.html
Аналогично с Perl, C, SQL и PL/pgSQL.
На интеренете много написано как сделать свой extension ( https://www.postgresql.org/docs/9.5/sta ... -pgxs.html ) .
Если вы его сделаете, то можете раздавать или продавать если найдёте покупателя. Надо, естественно, изучить легальную сторону вопроса т.к. postgres - это open source и лицензия налагает некие обязательства на коммерческое использование postgres.

Некоторые extensions поставляются в уже компилированном виде и их легко начать использовать, а некоторые есть только в виде source code и это уже не всегда легко, т.к. требует наличие environment.
Вот здесь ряд extensions от ряда разработчиков
https://www.postgresql.org/download/pro ... xtensions/
но есть и др. места также ( http://dhamaniasad.github.io/awesome-po ... extensions )
Пока я тут вам искал ссылки, обнаружил, что extension для языка R, а я и не знал:
http://www.bostongis.com/PrinterFriendl ... _plr_tut01

[Ion Tichy]

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

1. Аналогия с метрами-ярдами абсолютно не канает. В ИТ далеко на всегда надо "переходить", куча проектов может быть начата "с чистого листа"
2. "Удобство разработчиков" есть "повышение производительности труда" что оборачивается "снижением стоимости" и в результате может "повысить прибыль". Овчинка стОит выделки.

[OtherSide]

1. Аналогия с метрами-ярдами абсолютно не канает. В ИТ далеко на всегда надо "переходить", куча проектов может быть начата "с чистого листа"
2. "Удобство разработчиков" есть "повышение производительности труда" что оборачивается "снижением стоимости" и в результате может "повысить прибыль". Овчинка стОит выделки.

С чистого листа не выйдет. Потому что нужно будет искать разрабов на рынке под новый инструемент, а их не будет. Да и вообще мало ли на рынке кривых технологий, которыми пользуются или пользовались только из за их распространенности? Тот же флеш, win95, джаваскрипт тоже в свое время на коленке за 3 недели сделали и проч.

[Ion Tichy]

1. Аналогия с метрами-ярдами абсолютно не канает. В ИТ далеко на всегда надо "переходить", куча проектов может быть начата "с чистого листа"
2. "Удобство разработчиков" есть "повышение производительности труда" что оборачивается "снижением стоимости" и в результате может "повысить прибыль". Овчинка стОит выделки.

С чистого листа не выйдет. Потому что нужно будет искать разрабов на рынке под новый инструемент, а их не будет. Да и вообще мало ли на рынке кривых технологий, которыми пользуются или пользовались только из за их распространенности? Тот же флеш, win95, джаваскрипт тоже в свое время на коленке за 3 недели сделали и проч.

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

[Palych]

В postgres можно было внедрить как одну из многих опций для написания функций. В данный момент там поддерживается и sql, и plsql, и perl, и python, c и кажется ещё что-то.

кстати, а они предоставляют API для доступа к данным помимо SQL?
Или можно работать только с результатами SQL запросов?

Разработчики ( developer community) предоставляют исходный код с возможностью создания всякого рода extensions. Поддержка разных языков программирования осуществляется через extensions.

Спасибо за подробную информацию, но я не о языках для расширений хотел сказать, а о принципах их написания.
Согласно беглому взгляду - все эти расширения позволяют выполнять SQL запросы из процедурных языков, и/или передавать результаты запросов (отдельные записи, курсоры и проч) в процедурные языки.
Получается - сколько не расширяй PostgreSQL - SQL из него никуда не денется.

Другое дело - упомянутый здесь Spark SQL. Мне кажется это более интересный путь.
И он как раз (IMHO, бо я не спец по СУБД) позволяет преодолеть один из главных недостатков SQL: невозможность(хорошо - сложность) собрать сложные конструкции из простых, сохраняя читабельность кода.
При этом SQL остается на "бухгалтерском" уровне, без всякой эзотерики, сокровенных знаний, доступных только жрецам, и применимых только в определенные фазы Луны...

[Palych]

...
Это значит - если ОС или БД изменит распределение ресурсов, придется переписывать запросы?

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

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

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

[oleg lebedev]

В postgres можно было внедрить как одну из многих опций для написания функций. В данный момент там поддерживается и sql, и plsql, и perl, и python, c и кажется ещё что-то.

кстати, а они предоставляют API для доступа к данным помимо SQL?
Или можно работать только с результатами SQL запросов?

Разработчики ( developer community) предоставляют исходный код с возможностью создания всякого рода extensions. Поддержка разных языков программирования осуществляется через extensions.

Спасибо за подробную информацию, но я не о языках для расширений хотел сказать, а о принципах их написания.
Согласно беглому взгляду - все эти расширения позволяют выполнять SQL запросы из процедурных языков, и/или передавать результаты запросов (отдельные записи, курсоры и проч) в процедурные языки.
Получается - сколько не расширяй PostgreSQL - SQL из него никуда не денется.

Другое дело - упомянутый здесь Spark SQL. Мне кажется это более интересный путь.
И он как раз (IMHO, бо я не спец по СУБД) позволяет преодолеть один из главных недостатков SQL: невозможность(хорошо - сложность) собрать сложные конструкции из простых, сохраняя читабельность кода.
При этом SQL остается на "бухгалтерском" уровне, без всякой эзотерики, сокровенных знаний, доступных только жрецам, и применимых только в определенные фазы Луны...

Насколько я понимаю в том как обрабатываются запросы движком relational DB - написанное выше не совсем точное.
SQL - это лишь скрипт для человека, он потом парсается и оптимизатор ( главный интеллектуальный компонент) превращает его в execution plan. Одному и тому же SQL скрипту может соответствовать разные планы если изменилась статистика на таблицы, индексы, hardware. Скажем, поставили быстре RAID Array и план может поменяться, т.к. sequential scan может оказаться выгоднее чем чтение по индексу.
Этот execution plan содержит последовательность низкоуровневых шагов ( hash join, merge join и пр.) которые собственно и исполняются в виде read, write, CPU operations.
Так что SQL - это лишь стандарт правил для человека. Если вы его замените чем-то другим, то это лишь интерфейс.
Если же ваша цель - вообще поменять парадигму, например исключить optimizer, то это должно быть нечто другое чем то что понимается под relational DBs. Я не могу себе представить как можно исключить optimizer - т.к. это главный элемент адаптивной технодогии в БД, но это в силу моего восприятия, т.к. я работал с системами в которых он есть.

[oleg lebedev]

dup

[Palych]

Одному и тому же SQL скрипту может соответствовать разные планы если изменилась статистика на таблицы, индексы, hardware. Скажем, поставили быстре RAID Array и план может поменяться, т.к. sequential scan может оказаться выгоднее чем чтение по индексу.
Этот execution plan содержит последовательность низкоуровневых шагов ( hash join, merge join и пр.) которые собственно и исполняются в виде read, write, CPU operations.
Так что SQL - это лишь стандарт правил для человека. Если вы его замените чем-то другим, то это лишь интерфейс.
Если же ваша цель - вообще поменять парадигму, например исключить optimizer, то это должно быть нечто другое чем то что понимается под relational DBs. Я не могу себе представить как можно исключить optimizer - т.к. это главный элемент адаптивной технодогии в БД, но это в силу моего восприятия, т.к. я работал с системами в которых он есть.

По поводу принципов работы оптимизатора:
Если он в современных системах способен полностью автоматически выбрать правильный план - зачем разработчику нужно знать детали распределения ресурсов на уровне ОС?
Я не иронизирую, я действительно не знаю.
Мне со стороны история оптимизаторов напоминает сборку мусора в Java: с одной стороны на прикладном уровне невозможно явно управлять памятью и сборкой мусора, а с другой стороны - для оптимальной работы необходимо его настраивать, да ещё с учетом того как написан код...

[Ion Tichy]

...
Это значит - если ОС или БД изменит распределение ресурсов, придется переписывать запросы?

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

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

Ну типа десятилетиями ресурс был доступен по фтп на одном интранецком хосте с 23:00 до 23:30 местного времени в виде кобольных книг и вдруг - бац! - какой-то нах соап-овер-хттп...

[ak3]

Если я не ошибаюсь, то optimizer'а в мс сиквеле давно уже нет.
Там теперь algebrizer, whatever it is

[iDesperado]

SQL - это лишь скрипт для человека, он потом парсается и оптимизатор ( главный интеллектуальный компонент) превращает его в execution plan. Одному и тому же SQL скрипту может соответствовать разные планы если изменилась статистика на таблицы, индексы, hardware. Скажем, поставили быстре RAID Array и план может поменяться, т.к. sequential scan может оказаться выгоднее чем чтение по индексу.
Этот execution plan содержит последовательность низкоуровневых шагов ( hash join, merge join и пр.) которые собственно и исполняются в виде read, write, CPU operations.
Так что SQL - это лишь стандарт правил для человека. Если вы его замените чем-то другим, то это лишь интерфейс.

+1
главная передесть SQL то, что он декларативный язык. он не указывает как достать данные, он указывает какие данные достать. т.е. если данные с годами выросли, мне не нужно как с java выкидывать код, оптимизатор изменит SQL план, подстраиваясь под размеры таблиц.

[alex_127]

Если я не ошибаюсь, то optimizer'а в мс сиквеле давно уже нет.
Там теперь algebrizer, whatever it is

Это только часть трансформаций которые делаются перед запуском оптимизатора.

[alex_127]

Одному и тому же SQL скрипту может соответствовать разные планы если изменилась статистика на таблицы, индексы, hardware. Скажем, поставили быстре RAID Array и план может поменяться, т.к. sequential scan может оказаться выгоднее чем чтение по индексу.
Этот execution plan содержит последовательность низкоуровневых шагов ( hash join, merge join и пр.) которые собственно и исполняются в виде read, write, CPU operations.
Так что SQL - это лишь стандарт правил для человека. Если вы его замените чем-то другим, то это лишь интерфейс.
Если же ваша цель - вообще поменять парадигму, например исключить optimizer, то это должно быть нечто другое чем то что понимается под relational DBs. Я не могу себе представить как можно исключить optimizer - т.к. это главный элемент адаптивной технодогии в БД, но это в силу моего восприятия, т.к. я работал с системами в которых он есть.

По поводу принципов работы оптимизатора:
Если он в современных системах способен полностью автоматически выбрать правильный план - зачем разработчику нужно знать детали распределения ресурсов на уровне ОС?
Я не иронизирую, я действительно не знаю.
Мне со стороны история оптимизаторов напоминает сборку мусора в Java: с одной стороны на прикладном уровне невозможно явно управлять памятью и сборкой мусора, а с другой стороны - для оптимальной работы необходимо его настраивать, да ещё с учетом того как написан код...

Построение правильного плана может потребовать времени и ресурсов недоступных в системе, так что ищется не идеальный but "good enough". Есть 2 типа оптимизатора и за последние лет 20 новых не появилось. И все реальные поверх общей стратегии битком набиты "special cases" and heuristics.

[oshibka_residenta]

...
Это значит - если ОС или БД изменит распределение ресурсов, придется переписывать запросы?

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

Ваш пример не катит. У вас с женой поменялся интерфейс.
А если для того, чтобы работать с БД нужно знать как она работает на уровне ОС - в топку такую БД.