Comments 16
языку программирования SQL
SQL — это не язык программирования. Язык программирования — это programming language (PL), а SQL — structured query language, т.е. язык структурированных запросов.
Его реализация в Oracle кстати имеет совмещенное название: PL/SQL, что как бы подчеркивает тот факт, что в язык запросов внесены элементы от языка программирования.
Не совсем согласен с Вами.
Если честно, то для меня язык программирования (ЯП) — это всё, на чём человек может объяснить компьютеру, что тот должен делать. Так что, IMNSHO, SQL — это несомненно язык программирования. Специализированный. И Википедия тоже со мной согласна. Да, если бы язык имел устоявшееся название СЯЗ (Структурированный язык запросов), то с точки зрения русского языка его бы чаще называли языком запросов, как это и происходит в английском. А так, все формальные языки, придуманные для программирования ЭВМ, вполне корректно называть ЯП.
PL/SQL это как бы не SQL с дополнениями ЯП, а совершенно самостоятельный язык программирования с встроенной возможностью использовать в нём SQL. Тоже, кстати, довольно специализированный. Возможно, название было взято по аналогии с PL/I, который был популярен во время появления на рынке PL/SQL, хотя корнями PL/SQL ближе к ADA.
У меня просьба к коментаторам: если Вам кажется, что в тексте ошибка, то лучше в личные сообщения.
Если честно, то для меня язык программирования (ЯП) — это всё, на чём человек может объяснить компьютеру, что тот должен делать. Так что, IMNSHO, SQL — это несомненно язык программирования. Специализированный. И Википедия тоже со мной согласна. Да, если бы язык имел устоявшееся название СЯЗ (Структурированный язык запросов), то с точки зрения русского языка его бы чаще называли языком запросов, как это и происходит в английском. А так, все формальные языки, придуманные для программирования ЭВМ, вполне корректно называть ЯП.
PL/SQL это как бы не SQL с дополнениями ЯП, а совершенно самостоятельный язык программирования с встроенной возможностью использовать в нём SQL. Тоже, кстати, довольно специализированный. Возможно, название было взято по аналогии с PL/I, который был популярен во время появления на рынке PL/SQL, хотя корнями PL/SQL ближе к ADA.
У меня просьба к коментаторам: если Вам кажется, что в тексте ошибка, то лучше в личные сообщения.
Это не ошибка, а разница подходов к пониманию термина, что вы, собственно, и описали. Я потому и вынес это в комментарий, чтобы озвучить собственное мнение по этому поводу. Я категорически не согласен с формулировкой «язык программирования (ЯП) — это всё, на чём человек может объяснить компьютеру, что тот должен делать». Так у нас и Markdown и HTML превратятся в языки программирования, тогда как это языки разметки.
Ну и согласна с вами русскоязычная википедия, а вот англоязычная — нет. Да и упоминать Википедию как экспертный источник знаний — вещь сомнительная.
По анлгоязычной Википедии, есть общий класс «Computer language», к которому относятся языки программирования, запросов, разметки и т.д. и т.п.
https://en.wikipedia.org/wiki/Computer_language
Я, собственно, не планирую с жаром отстаивать свое мнение и вести активную дискуссию по поводу, просто небольшая ремарка, не имеющая отношения к смысловому наполнению статьи — статья хорошая и интересная, задачки крутые, на мой взгляд, я может быть даже попробую их порешать, поэтому поддерживаю отсутствие готовых ответов в статье — интереснее решать, не имея искушения в виде возможности подглядеть правильный ответ.
Ну и согласна с вами русскоязычная википедия, а вот англоязычная — нет. Да и упоминать Википедию как экспертный источник знаний — вещь сомнительная.
По анлгоязычной Википедии, есть общий класс «Computer language», к которому относятся языки программирования, запросов, разметки и т.д. и т.п.
https://en.wikipedia.org/wiki/Computer_language
Я, собственно, не планирую с жаром отстаивать свое мнение и вести активную дискуссию по поводу, просто небольшая ремарка, не имеющая отношения к смысловому наполнению статьи — статья хорошая и интересная, задачки крутые, на мой взгляд, я может быть даже попробую их порешать, поэтому поддерживаю отсутствие готовых ответов в статье — интереснее решать, не имея искушения в виде возможности подглядеть правильный ответ.
За конструктивный подход спасибо, так можно и подискутировать. Хотя я несколько опасаюсь Вашего «категорического несогласия» (цитата). Зачем же категорично так?
Английская Википедия тоже называет SQL специализированным языком
(DSL), используемым в программировании. По английски просто писать, что query language является ещё каким-то language — это толочь воду в ступе, название самоопредеяющее.
На самом деле порывшись в Википедии я так понимаю, что Вы различаете компьютерные языки и в них подкласс языков программирования, а я все компьютерные языки называю ЯП. Если честно, не знаю насколько это сложившаяся терминология, даже несморя на профильное образование и десятилетия работы в области ИТ.
В моём представлении компьютерным языком можно назвать вообще что угодно, связанное с языком и компьютером. Например то, что мне какая-то работающая на компьютере программа покажет на экране. Текстовый вывод любой программы, особенно если он человеко-подобный (типа введите число) можно назвать компьютерным языком. Или все эти текстовые протоколы, на которых общаются сами программы (http, smtp и прочее). Сюда же, кстати, SQL вписывается. Короче слишком общо, мне не нравится. Хотя да, языки разметки в ЯП записывать тоже не совсем корректно. С третьей стороны на том же XML есть XSLT и это уже ЯП в самом что ни на есть программистском понимании. Да и на CSS порой такой интерактив делают, что ой. Так что по крайней мере не всё так однозначно.
И ещё хочу пару слов в защиту Википедии сказать. Почему-то её принято походу пинать, что она не является авторитетом. Почему ж не является? Ещё как является. Истиной в последней инстанции не является, а энциклопедическим изданием является и весьма неплохим. В Hitchhikers Guide to the Galaxy ляпов куда как больше.
Английская Википедия тоже называет SQL специализированным языком
(DSL), используемым в программировании. По английски просто писать, что query language является ещё каким-то language — это толочь воду в ступе, название самоопредеяющее.
На самом деле порывшись в Википедии я так понимаю, что Вы различаете компьютерные языки и в них подкласс языков программирования, а я все компьютерные языки называю ЯП. Если честно, не знаю насколько это сложившаяся терминология, даже несморя на профильное образование и десятилетия работы в области ИТ.
В моём представлении компьютерным языком можно назвать вообще что угодно, связанное с языком и компьютером. Например то, что мне какая-то работающая на компьютере программа покажет на экране. Текстовый вывод любой программы, особенно если он человеко-подобный (типа введите число) можно назвать компьютерным языком. Или все эти текстовые протоколы, на которых общаются сами программы (http, smtp и прочее). Сюда же, кстати, SQL вписывается. Короче слишком общо, мне не нравится. Хотя да, языки разметки в ЯП записывать тоже не совсем корректно. С третьей стороны на том же XML есть XSLT и это уже ЯП в самом что ни на есть программистском понимании. Да и на CSS порой такой интерактив делают, что ой. Так что по крайней мере не всё так однозначно.
И ещё хочу пару слов в защиту Википедии сказать. Почему-то её принято походу пинать, что она не является авторитетом. Почему ж не является? Ещё как является. Истиной в последней инстанции не является, а энциклопедическим изданием является и весьма неплохим. В Hitchhikers Guide to the Galaxy ляпов куда как больше.
UFO just landed and posted this here
А надо? Если делать разбор задачи, то нужно по статье на каждую. Просто опубликовать ответы, на мой вкус, неинтересно, их никто тогда не будет и пробовать решать. Ну и я не вижу никакой запредельной сложности в этих задачах.
UFO just landed and posted this here
А Вы не скромничайте и попробуйте сами. Это не так сложно, как кажется. Самое сложное, что там есть — это не совсем традиционное использование рекурсии. И уж точно тут нет никакой олимпиадной специфики. Подобные задачки время от времени рассматривают на sql.ru, посмотрите там на примеры разбора.
Подскажите в какую сторону копать, что читать для решения задачи про кувшины? К остальным даже не пробую пока подходить. На работе Oracle 10.2, рекурсии на практике применять не приходилось (максимум connect by для запроса значений из строки, да построения простеньких деревьев по типу parentID = ID). Почитал про рекурсии на Oracle 11 через WITH, но понимания как применить это по отношению к задаче не пришло. Догадываюсь, что результат собираются через SYS_CONNECT_BY_PATH (wm_concat бы, но он недокументированный =/).
P.S. Работаю с Oracle SQL/PLSQL несколько лет, но уже второй раз проходя во второй тур понимаю какой я лох.
P.S. Работаю с Oracle SQL/PLSQL несколько лет, но уже второй раз проходя во второй тур понимаю какой я лох.
Как жаль, что я не знал про это мероприятие… Обязательно бы поучаствовал, и волновой алгоритм очень уважаю… Чего только на SQL не делал… На сайте sql-ex решал похожие задачи, в MSSQL Server, там даже на парсер выражений задачи есть, ага :) С Ораклом на работе дело имею, так что подтянулся бы заодно… Ну вы это, в следующий раз на хабре заранее анонсируйте подобные мероприятия, глядишь народу будет побольше :)
Такой метод работает быстро и оптимально находит кратчайший путь, отбрасывая заведомо более плохие варианты, но сложнее в реализации.
Волновой алгоритм в Оракле реализуется довольно тривиально с помощью рекурсивного запроса с «search breadth first».
Задачки в целом любопытные, но не понятно, почему именно такие. Реализация парсера, например, совершенно нетипична для sql и скорее подходит для императивных языков.
"В один запрос" тоже странное ограничение. Если его убрать, то можно придумать задачу на анализ данных, которая реализуется в несколько шагов и где нужно поискать баланс между скоростью работы и объемом промежуточных таблиц.
Можно еще дать структуру таблиц, какой-нибудь аналитический запрос по ней и поставить задачу на миграцию данных с целью максимального ускорения аналитического запроса.
Парсер — это в калькуляторе? Специально так подбирали условие, чтобы от парсера там был один подзапрос с регулярным выражением. Не думаю, что это было проблемой хоть для кого-то, кто взялся за решение задачи.
А вот как Вы себе представляете задачу по ускорению аналитического запроса? Я без всяких шуток интересуюсь. Просто для меня миграция данных — это как взял лопату и «бери больше, кидай дальше», никаких сложностей сплошная рутина. Что тут оценивать-то?
А вот как Вы себе представляете задачу по ускорению аналитического запроса? Я без всяких шуток интересуюсь. Просто для меня миграция данных — это как взял лопату и «бери больше, кидай дальше», никаких сложностей сплошная рутина. Что тут оценивать-то?
Ускорения аналитического запроса можно добиться за счет частичной денормализации данных.
Допустим приложение живет на одной структуре таблиц, оптимизированной под real-time операции, но по этой структуре неудобно делать аналитику, т.к. нужно множество джойнов и вложенных подзапросов. Если аналитические запросы с джойнами выполняются часто, то будут работать долго. Но при этом данные для них подходят "вчерашние", а значит можно "на ночь" поставить пересчет денормализованных таблиц, по которым выборка будет быстрее. При этом данные за несколько лет каждую ночь пересчитывать будет накладно и нужно суметь выразить дельту за вчерашний день и корректно ее соединить с результатом расчета прошлой ночью.
Оценивать олимпиадные работы по критериям: время работы полного пересчета данных, время работы ночного пересчета дельты, время работы оперативного аналитического запроса, соответствие результатов старого и нового аналитического запроса.
Ну нет, не годится. Даже мне, человеку довольно далёкому от оптимизации, ясно, что время работы будет зависеть много от чего, включая заполненность кэшей базы и особенности физического распределения данных по дискам (читай: от погоды на луне). То есть объективно сравнить два решения будет совершенно невозможно. Обычно оптимизацию хоть как-то меряют по количеству логических чтений. Это раз. А во-вторых, с точки зрения олимпиады, это уже не задача на SQL получается, а оптимизация работы некоей IT-системы.
Плюс, вопросы оптимизации они такие, мягко говоря не совсем простые по критериям. Обычно оптимизация ведётся до приемлемого уровня, планка которого для каждого конкретного случая выставляется в определённую конкретную величину, которую можно померять.
Потому что любое улучшение производительности не даётся просто так. После исправления первых глупостей, где банально неправильно похватывается план исполнения, дальше приходится за любое улучшение скорости платить, и платить немало. Это статистика для оптимизатора, дополнительные индексы, промежуточное хранение или денормализация данных, изменение алгоритмов обработки и т.п. И чем дальше, тем больше приходится изголяться. Вплоть до признания, что такое-то значение за такое-то время из базы получить невозможно, давайте выбирать что-то другое, что можно получить, то есть изменение постановки задачи. Поэтому остановиться надо сразу, как только приемлемый уровень производительности достигнут.
Вобщем тема оптимизации несомненно интересна и очень востребована, но олимпиада была по SQL. Как в SQL дать задачу на производительность мы придумали, см. задачи 8 и 9 финала. А аналитические хранилищи оптимизировать, это наверное не на олимпиаде, а на производстве с 09 до 18.
Плюс, вопросы оптимизации они такие, мягко говоря не совсем простые по критериям. Обычно оптимизация ведётся до приемлемого уровня, планка которого для каждого конкретного случая выставляется в определённую конкретную величину, которую можно померять.
Потому что любое улучшение производительности не даётся просто так. После исправления первых глупостей, где банально неправильно похватывается план исполнения, дальше приходится за любое улучшение скорости платить, и платить немало. Это статистика для оптимизатора, дополнительные индексы, промежуточное хранение или денормализация данных, изменение алгоритмов обработки и т.п. И чем дальше, тем больше приходится изголяться. Вплоть до признания, что такое-то значение за такое-то время из базы получить невозможно, давайте выбирать что-то другое, что можно получить, то есть изменение постановки задачи. Поэтому остановиться надо сразу, как только приемлемый уровень производительности достигнут.
Вобщем тема оптимизации несомненно интересна и очень востребована, но олимпиада была по SQL. Как в SQL дать задачу на производительность мы придумали, см. задачи 8 и 9 финала. А аналитические хранилищи оптимизировать, это наверное не на олимпиаде, а на производстве с 09 до 18.
Sign up to leave a comment.
Как мы делали олимпиаду по SQL