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

[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]

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

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

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