Компания Couchbase, развивающая (https://www.opennet.ru/opennews/art.shtml?num=29528) такие системы, как CouchDB, Memcached и Membase, анонсировала (http://www.couchbase.com/press-releases/unql-query-language) создание нового языка запросов - UnQL (http://www.unqlspec.org) (Unstructured Data Query Language), напоминающего SQL, но ориентированного на работу с неструктурированными данными. Проект выполнен совместными усилиями Ричарда Гиппа (Richard Hipp), создателя SQLite, и Дэмиена Каца (Damien Katz), основателя проекта CouchDB. Разработка передана сообществу в виде общественного достояния.
Основной целью разработки было создание для NoSQL-систем привычного и стандартизованного языка для определения и манипулирования данными. UnQL выступает в роли неструктурированного эквивалента SQL и призван заполнить образовавшуюся нишу, связанную с отсутствием единой формы задания модели данных и языка запросов, которые могли бы стать стандартом для нереляционных баз данных, манипулирующих нестр...URL: http://www.couchbase.com/press-releases/unql-query-language
Новость: https://www.opennet.ru/opennews/art.shtml?num=31346
Типа чтобы вместо SQL иньекций были UnQL иньекции? Вообще-то главные плюсы nosql это то что не надо тратить время на разбор синтаксиса каких-то там языков и нет риска что какой-то урод заиньектит команды. Спасибо, но исправлять эти два "недостатка" не требуется.
injection это косяк языков работающих с СУБД, но не самих СУБД. Запретить в драйвере PHP делать конкатенацию WHERE, заставить работать через связанные переменные и инжекции исчезнут как класс =)))
В драйвере PHP? ага, хорошо сказал
Попробуйте допустить такой косяк в базе ключ-значение? :) Хоть на пыхпыхе хоть на чем там вам угодно. Как бы там фича в том что тип операции задается в коде, а передаваемые параметры ну никак не изменят тип операции. Т.е. допустим поиск значения ну никак не превратиться в дроп таблицы. Это довольно ощутимый плюс: иньектить становится просто нечего и незачем. Чем проще конструкция тем она надежнее. Гольный key-value хрен сломаешь.
Там, где есть 'WHERE', всегда можно вставить ' OR своё условие'.
не k-v storage единым жив NoSQL
Откройте для себя mysqli. Используем prepare и bind_param и SQL-injections нам не страшны.
А использовать хранимые процедурки и к ним обращаться - не проще ли? И не эффективней ли, чем в коде каждый раз препарировать запрос, выполняя, как минимум, лишние повторы парсинга кода?
> А использовать хранимые процедурки и к ним обращаться - не проще ли? И не эффективней ли, чем в коде каждый раз препарировать запрос, выполняя, как минимум, лишние повторы парсинга кода?Вообще то prepared statements и stored procedures - это как бы ортогональные друг-другу вещи. Как скажем мягкое и фиолетовое. Естественно что независимо от конкретной RDBMS будь то MySQL, Oracle или кто-то другой.
> нет риска что какой-то урод заиньектит командыэтого риска нет в любом случае, если у программиста руки не из Ж растут
каждый раз когда программист занимается формированием строки "A + B + C" (из нескольких разных компонентов, некоторые из которых константны а некоторые переменны) -- он ЧЁТКО пониает границы за которые могут выходить "A" "B" "C" ...
...и не важно что это SQL, или HTML, или SHELL_CMD, или BLAHBLAHBLAH.... принцып везде один и тотже: "ПЕРЕМЕННАЯ-СОСТОВЛЯЮЩАЯ, НАХОДЯЩАЯСЯ ВНУТРИ ПОСТОЯННОЙ СОСТОВЛЯЮЩЕЙ -- ДОЛЖНА БЫТЬ ПЕРЕДАНА В СООТВЕТСТВУЮЩЕМ ВИДЕ, А НЕ ПУТЁМ ПРОСТОЙ ПОДСТАНОВКИ"
# p.s.: я НЕ имею ввиду что программисту нужно *вручную* каждый раз формировать "A + B + C".. но понимать как оно формируется -- он просто обязан
> этого риска нет в любом случае, если у программиста руки не из Ж растутОн всегда есть, потому что параметры передаются вместе с самим запросом, юзер на них может воздействовать, а соревнование кто кого перехитрит и обойдет на повороте (юзер программера или программер юзера) - практически бесконечное.
> -- он ЧЁТКО пониает границы за которые могут выходить "A" "B" "C" ...
При чем тут вообще границы? Проблема скуля в том что он часто работает с внешними не доверяемыми данными. При том он не делает особых различий между операцией и данными для нее, и позволяет несколько операций в одном запросе. Поэтому без спецмер со стороны программера select из таблицы пользователей легко превращается в например ее дроп или произвольный вызов функционала БД, путем указания имени юзера в стиле того комикса про "little Jonny the tables we call him" ;). Понятно что можно програмера построить, заставить проверять что там ему юзер подсунул и прочая. Тут начинается густое костылирование всякими эскейпами (которые порой мешают жить в легитимных случаях и сажают скорость работы) и соревнование - нащупает ли хакер слабину или нет.
> -- ДОЛЖНА БЫТЬ ПЕРЕДАНА В СООТВЕТСТВУЮЩЕМ ВИДЕ, А НЕ ПУТЁМ ПРОСТОЙ
> ПОДСТАНОВКИ"В key-value базу можно и путем простой подстановки пхать. Во всяком случае, это не приведет к таким разрушительным последствиям как в скуле.
> # p.s.: я НЕ имею ввиду что программисту нужно *вручную* каждый раз
> формировать "A + B + C".. но понимать как оно формируется
> -- он просто обязанВ случае скуля приходится именно вручную костылить все что может вводиться юзером жесточайшими эскейпами. Совсем не ускоряющими операции, выносящими мозг временами и в результате - скуль-иньекции давно стали привычным классом дыр. А попробуйте в nosql типа ключ-значение чего-то заиньектить вообще? :)
Если Вы не знаете, что такое "границы", их проверка и подготовка значений - не делайте голословных заявлений о рисках ;-)В случае скуля не приходится ровным счётом ничего "вручную костылить". Начиная от prepared statements, реализуемых драйвером автоматически, заканчивая соответствующими escape-функциями, позволяющими программисту тонко контролировать процесс.
Если у Вас база получает непроверенные данные - это таки Ваши проблемы, а не проблемы базы.
Если программера нужно "строить" чтобы он выполнял свою работу, то не пошёл ли такой программер лесом в известном направлении?
> В key-value базу можно и путем простой подстановки пхать.
Интересно увидеть пример такой простой подстановки, если типичный интерфейс передачи параметров подобен prepareStatement.
> В случае скуля не приходится ровным счётом ничего "вручную костылить". Начиная от
> prepared statements, реализуемых драйвером автоматически, заканчивая соответствующими
> escape-функциями, позволяющими программисту тонко контролировать процесс.Автоматизация костылестроения и тюнинг костылей. Шедеврально.
А в базах ключ-значение в выражении вида value = get(key) вообще облажаться негде. Юзер может пхать как key все что хочет даже. Но это мало ему поможет. И не надо никакого эскейпинга, prepare statement и прочих костылей. Можно влобешник имя пользователя отдать как key без особых рисков. Стоит ли говорить что базы key-value сами по себе просто убойно быстрые, да еще и дополнительно тормозить эскейпингами и prepare statements не надо.
Признаюсь, я никогди не работал с не SQL СУБД, поэтому мне сложно судить нужен ли UnSQL. Но давайте представим, что SQL не стандарт, тогда каждый разработчик (производитель) реляционной СУБД придумывал бы свои язык запросов, и это учитывая то, что сейчас у каждой реляционной СУБД итак есть свои небольшие отклонения от стандарта SQL.
> тогда каждый разработчик (производитель) реляционной СУБД придумывал бы свои язык запросова NoSQL обычно не реляционные. опаньки.
> Признаюсь, я никогди не работал с не SQL СУБД, поэтому мне сложно
> судить нужен ли UnSQL.Да чего уж там, давайте допустим что по другому работать с базами вообще нельзя. Куда уж нам ключ-значение например освоить.Это же думать надо, а не сбагривать десятиэтажный запрос движку, который как-нибудь подразопрется. Слив в 20 раз по производительности и позволив over 9000 возможных атак на базу.
> Слив в
> 20 раз по производительности и позволив over 9000 возможных атак на
> базу.В 20? Относительно CouchDb mapreduce "слив" в 2000 раз на сложных запросах.
> Вообще-то главные плюсы nosql
> это то что не надо тратить время на разбор синтаксиса каких-то
> там языков и нет риска что какой-то урод заиньектит команды.мда. похапэ на марше. вообще-то, «главные плюсы NoSQL» совсем не в этом. да и вообще, что такое это ваше «NoSQL»? вот HailDB — это подходит? или ещё не кошерно?
Самый кошерный nosql - базы типа ключ-значение. Убойно быстро. И не хакабельно практически. Ну да, единственный недостаток (для быдлокодеров) ровно один: надо думать головой, а не просто наворачивать немеряные select * ..., которые потом всю таблицу на уйму записей при каждом запросе читают :)Вообще, sql позволяет наворачивать одним махом конструкции которые потом лопатят всю базу на каждый чих. Чем сильно способствует процветанию быдлокодинга и повышению спроса на мощные сервера, попутно с выбросами CO2 :).
> единственный недостаток (для быдлокодеров) ровно один: надо думать
> головой, а не просто наворачивать немеряные select * ..., которые потом
> всю таблицу на уйму записей при каждом запросе читают :)1. Умные люди стоят денег, а их не так много, и людей и денег.
2. С усложнением структуры базы требуемая квалификация команды и тестеров,
как и их стоимость, возрастает геометрически.
Убогость, она не в технологии, она в головах.
Есть ниша для реализаций на Berkley DB, но ряд задач на
нереляцеонных БД удовлетворительно не решить.
> 1. Умные люди стоят денег, а их не так много, и людей
> и денег.Ну так нормальный человек стремится поумнеть. Зачем же деградантствовать и полагать что так и надо?
> 2. С усложнением структуры базы требуемая квалификация команды и тестеров,
> как и их стоимость, возрастает геометрически.Keep it simple, stupid! Да, конечно, на sql.ru можно найти и пример создания базы с 126 столбцами. Какой-то быдлoкодер решил что если движок может - давайте все в отдельной колонке хранить. Вплоть до цвета шрифта в конкретном месте страницы. Вот только такие продукты обычно тормозные, глюкавые и являют собой решетo.
> Убoгость, она не в технологии, она в головах.
Технология может способствовать убoгим решениям а может наоборот усложнять быдлoкодинг.
> Есть ниша для реализаций на Berkley DB, но ряд задач на
> нереляцеонных БД удовлетворительно не решить.А может просто не надо чрезмерно наворачивать структуру базы? А то сами же потом и будете лaжаться. Базы типа беркелея заставят намного тщательнее подходить к проектированию структуры базы и запросов. И не то чтобы результат от этого станет хуже.
> Самый кошерный nosql - базы типа ключ-значение. Убойно быстро. И не хакабельно
> практически. Ну да, единственный недостаток (для быдлокодеров) ровно один: надо думать
> головой, а не просто наворачивать немеряные select * ..., которые потом
> всю таблицу на уйму записей при каждом запросе читают :)
> Вообще, sql позволяет наворачивать одним махом конструкции которые потом лопатят всю базу
> на каждый чих. Чем сильно способствует процветанию быдлокодинга и повышению спроса
> на мощные сервера, попутно с выбросами CO2 :).CO2 вообще уже давно мало кого волнуют. В корпоративном мире уже давно царствует пожирающий ресурсы Java, а о качественном коде уже никто не думает, лишь бы работало и как можно быстрее.
> лишь бы работало и как можно быстрее.ну, то есть, лишь бы работало и *писалось как можно быстрее*.
> CO2 вообще уже давно мало кого волнуют.Так то от скудоумия. Планета у нас одна. Другой - нет. Засрем - вымрем как мамонты!
И никакие доллары не помогут.
интересно как оно все тормозит...
если есть документооборот с кучей фирм и каждая в своем формате данные предоставляет, то может и есть смысл...
А какой практический смысл введения UnQL?
Хотя в принципе наверное глобальный UPDATE или LEFT JOIN коллекций сделать на стороне базы будет быстрее чем в скриптах. Или я ошибаюсь?
> А какой практический смысл введения UnQL?привлечение большего количества обезьян.
> А какой практический смысл введения UnQL?переносимость приложений между NoSQL БД, плюс быстрее народ будет въезжать как работать с этими такими странными СУБД
> переносимость приложений между NoSQL БД, плюс быстрее народ будет въезжать как работать
> с этими такими странными СУБДДа, специально обученные обезьяны которые еле освоили синтаксис для даунов придут, и начнут лажать и в UnSQL и начнутся UnSQL иньекции. Как мило. Мало нам sql иньекций, давайте nosql-иньекции стандартизуем :).И что, опять мудохаться с эскейпингом имен пользователей и прочий онанизм? А не пошли бы вы?
>> переносимость приложений между NoSQL БД, плюс быстрее народ будет въезжать как работать
>> с этими такими странными СУБД
> Да, специально обученные обезьяны которые еле освоили синтаксис для даунов придут, и
> начнут лажать и в UnSQL и начнутся UnSQL иньекции. Как мило.
> Мало нам sql иньекций, давайте nosql-иньекции стандартизуем :).И что, опять мудохаться
> с эскейпингом имен пользователей и прочий онанизм? А не пошли бы
> вы?Чудаки хватит уже недостатки PHP выдавать за общие... или PHP считать единственным правильным языком. В той же Java несколько раз негативно упомянутой инъекции отсутствуют как класс =)
а мы и ушли на более интересные языки программирования нежели PHP ;)
>>В той же Java несколько раз негативно упомянутой инъекции отсутствуют как классДа вы сударь врете. Вот выдержка из гайда самого популярного java-ORM фреймворка Hibernate:
A note about SQL injection
Hibernate does not grant immunity to SQL Injection, one can misuse the api as they please.
There is nothing special about HQL (Hibernates subset of SQL) that makes it any more or less susceptible.
Functions such as createQuery(String query) and createSQLQuery(String query) create a Query object that will be executed when the call to commit() is made. If the query string is tainted you have sql injection. The details of these functions are covered later.
> Чудаки хватит уже недостатки PHP выдавать за общие...В каком месте я вообще хоть слово про пхп сказал? У вас какие-то личные счеты к пыху?
А вы пробовали делать выборки данных для какой-нибудь NoSQL? Вот пример как выглядит sql и выборка для MongoDB. Простая задача: посчитать сколько запросов сделал каждый пользователь
http://yfrog.com/z/kfiwnjp
Интересно, когда они для couchdb это реализуют?..
UnQL — это SQL для NoSQL, только без SQL.
> UnQL — это SQL для NoSQL, только без SQL.Next step NoUnQL?
> Next step NoUnQL?А потом UnUnSQL? А на какой итерации наступает stack overflow? :)
потом добавят реляционность, потом жёсткие схемы данных, потом… wait! oh, shi~~~~~~
Причём берут из реляционных БД худшие черты. Это надо же - SQL взять за образец.
> Причём берут из реляционных БД худшие черты.
> Это надо же - SQL взять за образец.А что надо было брать за образец?
Tutorial/Industrial D
nosql is a joke
какая разница что в качестве запросов - sql или жабаскрипт?
> nosql is a joke
> какая разница что в качестве запросов - sql или жабаскрипт?NoSQL сами по себе не оперируют ява-скриптом.А из какого языка приедет запрос к базе - вообще не принципиально. И плюс в том что например юзер введя вместо имени alert("db pwned!") нифига не поимеет удаленную базу, в отличие от скуля где это на каждом шагу, по поводу чего процветает постоянное затыкание этой "фичи" костылями и подпорками, защищающими движок бд от добрых пользователей. При том не совсем понятно почему задача обороны движка от юзеров спихана на какого-то стороннего програмера, который в этом может быть не ас а полный ass.
> NoSQL сами по себе не оперируют ява-скриптом.Смотря какие CouchDB как раз оперирует. Все донные хранятся в json. Все вычисления(map/reduce) на javascript, конфигурация и тесты тоже. В зависимостях тянет спайдерманки.
>> nosql is a joke
>> какая разница что в качестве запросов - sql или жабаскрипт?
> NoSQL сами по себе не оперируют ява-скриптом.А из какого языка приедет запрос
> к базе - вообще не принципиально. И плюс в том что
> например юзер введя вместо имени alert("db pwned!") нифига не поимеет удаленную
> базу, в отличие от скуля где это на каждом шагу, по
> поводу чего процветает постоянное затыкание этой "фичи" костылями и подпорками, защищающими
> движок бд от добрых пользователей. При том не совсем понятно почему
> задача обороны движка от юзеров спихана на какого-то стороннего програмера, который
> в этом может быть не ас а полный ass."на каждом шагу" - это такая гипербола, литературный оборот, да?
и вообще эскейпинг спасет отца русской демократии, ага
> и вообще эскейпинг спасет отца русской демократии, агаТы это скажи программистам например vBulletin в котором очередной раз обнаружили не фильтруемое поле, на этот раз Referer.
Ты предлагаешь проверять все устанавливаемые фреймворки и готовые решения на уязвимости?
Миллионы строк кода? Правда?
> "на каждом шагу" - это такая гипербола, литературный оборот, да?
> и вообще эскейпинг спасет отца русской демократии, агаЭскейпинг не нужен - нужен адекватный код работы с СУБД.
> "на каждом шагу" - это такая гипербола, литературный оборот, да?
> и вообще эскейпинг спасет отца русской демократии, агаПо аналогии, можно сначала специально сломать вам ногу а потом рассказать что костыли и гипс - спасут отца русской демократии. И что в них после тренировки можно даже бегать понемногу.
>>nosql is a joke какая разница что в качестве запросов - sql или жабаскрипт?А это не вы случайно для Сони сайты писали?
а у вас подробности взлома, сэр?
По данным, озвученным на BlackHat, с помощью SQL injection за год взламывается более 10 000 00 сайтов. Инжекции самая распространенная уязвимость, каждая вторая используемая уязвимость - имеет такую природу.
Вот сами полюбуйтесь LizaMoon(подтверждено что Kиза использует SQL inj):
http://www.google.com/#sclient=psy&hl=en&q=%22%3Cs...*%2Fur.php%22&aq=f&aqi=&aql=&oq=&pbx=1&fp=1&cad=b&bav=on.2,or.r_gc.r_pw.
1 800 000 сайтов.
Ссылка побилась:
http://goo.gl/H0U9h
Какая редчайшая чушь...1. Реляционные базы, будучи построены на одной и той же теории, могут использовать один и тот же язык (ну, с точностью до извращений/инноваций). NoSQL-базы под собой общей теории не имеют и различаются кардинально. Какой тут, на фиг, стнадартизированный язык, если между ними общего - ровно то, что в базу можно как-то положить данные, и еще как-то их извлечь? Да они для Mongo и Couch - и то компромисс не найдут.
2. Копировать SQL - это явная ошибка. Язык разрабатывался так, чтобы запросы писали люди (причём даже не программисты). Сейчас, когда большинство запросов генерируетс, а уж непрофессионалы их точно не пишут, синтаксис SQL - дикость, неудобная ни в генерации (а ну давай, собери все части запроса в нужной последовательности, с нужными разделителями и т.д.) ни в парсинге (что отлично видим на примере HandlerSocket). Если уж делать язык - надо его делать удобным для текущих применений,благо это не так сложно.
3. То же касается JSON. Его неудобно читать, а писать - ещё неудобнее, так как строг излишне. Если не нашли ничего приличнее, то, как минимум, надо использовать его надмнжество, допускающее необязательные запятые перед закрывающей скобкой массива или объекта, задание ключей без кавычек если ключ без пробелов и прочих спецсимволов. И, кстати, запятые между элементами массива/объекта можно вообще сделать необязательными - разбор остаётся абсолютно однозначным. Тогда имеем то, что легко может написать человек, м автоматически генерированный JSON воспринимается корректно.
Нет никаких проблем в парсинге и генерации SQL, есть только проблемы его интерпретирования на уровне СУБД, что от синтаксиса языка никак не зависит.Язык типа SQL и сейчас нужен в большей степени для анализа людьми, т.е. всё равно должен быть ньюман-френдли. Кроме дебила программиста и условного ORMа есть кучка DBAшников которые потом эти говнотворения читают переделывают в нормальный вид.
> есть кучка DBAшников которые потом эти гoвнoтворения читают переделывают в
> нормальный вид.и тогда всё ВНИЗАПНА! перестаёт работать.
>> есть кучка DBAшников которые потом эти гoвнoтворения читают переделывают в
>> нормальный вид.
> и тогда всё ВНИЗАПНА! перестаёт работать.Сюрприз - вменяемый ДБА правит так, что SQL-код начинает работать и работать быстро.
В моей практике был случай, когда косо написанный запрос молотил таблицу в 800 млрд строк (это не опечатка) и работал 48 часов. После вмеяемого переписывания опытным ДБА он стал работать 20 минут. ВНЕЗАПНО! Давая те же самые результаты.
> В моей практике был случай, когда косо написанный запрос молотил таблицу в
> 800 млрд строк (это не опечатка) и работал 48 часов. После
> вмеяемого переписывания опытным ДБА он стал работать 20 минут. ВНЕЗАПНО! Давая
> те же самые результаты.В моей практике удавалось путем переписывания запросов сократить время выполнения с 15+ минут до 0.001 сек. Человечек ухитрился соорудить каскад вложенных селектов там, где достаточно было WHERE x AND y AND z...
>> В моей практике был случай, когда косо написанный запрос молотил таблицу в
>> 800 млрд строк (это не опечатка) и работал 48 часов. После
>> вмеяемого переписывания опытным ДБА он стал работать 20 минут. ВНЕЗАПНО! Давая
>> те же самые результаты.
> В моей практике удавалось путем переписывания запросов сократить время выполнения с 15+
> минут до 0.001 сек. Человечек ухитрился соорудить каскад вложенных селектов там,
> где достаточно было WHERE x AND y AND z...из той же серии кривых ручек: года четыре назад приходило несколько клиентов, с еле ворочающимся битриксом, достаточно было правильные сделать индексы и запросы, работавшие по 60 сек., отрабатывали за 0.01
> Сюрприз — вменяемый ДБА правит так, что SQL-код начинает работать и работать
> быстро.вменяемых DBA очень мало, увы. а если DBA пригласили уже *после* того, как набыдлокодили — то во вменяемость верится слабо. потому что сами клиенты совершенно невменяемые, и «профессионала» найдут себе под стать.
> Сюрприз - вменяемый ДБА правит так, что SQL-код начинает работать и работать
> быстро.Сюрприз: базу key-value до уровня скуля затормозить - надо сиииииииильно постараться. Например токийский кабинет возвращает значение по ключу в 1 или 2 дисковые операции. На-ка, тормозни его, DBA.
а при чем здесь SQL? вы сравниваете BTREE с Hash-таблицей.
Основная проблема в генерации SQL - то, что в нём конструкции не могут идти в произвольном порядке. То есть если нам извне пришел запрос, мы так просто на него, скажем, дополнительное условие не наложим - потому что после WHERE может идти какой-нибудь HAVING. Только полностью разбирать, добавлять что надо и снова собирать. Или другой пример - при сборке вместо того, чтобы тупо всё совать в строку, нам надо держать семиэтажную структуру - здесь у нас таблицы, которые пойдут во FROM, там поля для SELECT и так далее. При этом ни малейшего обоснования этого дела нет - просто исторически сложилось с тех времён, когда подразумевалось, что запросы будут писать люди, и даже не программисты - и соответственно запросы пытались сделать похожими на выражения английского языка.Что до парсинга - я парсер SQL не писал, так что в чем там проблемы не знаю - однако HandlerSocket за счет отказа от SQL-синтаксиса дает приличный выигрыш.
Нет никаких проблем то, чо нагенерила софтина, нормализовать в случае надобности для чтения человеком.
> Основная проблема в генерации SQL - то, что в нём конструкции не могут идти в произвольном порядке. То есть если нам извне пришел запрос, мы так просто на него, скажем, дополнительное условие не наложим - потому что после WHERE может идти какой-нибудь HAVING. Только полностью разбирать, добавлять что надо и снова собирать.Просто это операция типа конкатенации строк? Ну так ни к какому языку такого типа нельзя наложить доп. условие даже если формально можно добавить текст кода в конец выражения. Для корректного результата везде нужно проводить полный синтаксический и логический анализ всего выражения. Это не проблема SQL, а прямое следствие отдалённости требуемого конечного результата от начальной структуры данных.
Т.е. я утверждаю, что не придумаешь такую же функциональную альтернативу без этого недостатка. Это из серии 'выберите любое 2 из 3'
> Или другой пример - при сборке вместо того, чтобы тупо всё совать в строку, нам надо держать семиэтажную структуру - здесь у нас таблицы, которые пойдут во FROM, там поля для SELECT и так далее.
Это от части отражение декларативного характера SQL, а не императивного, где как раз можно всё набросать в кучу. Во-вторых, отражение логики обработки запросов в СУБД и порсто выстроение декларации в логическую линию. И это тру вей.
> При этом ни малейшего обоснования этого дела нет - просто исторически сложилось с тех времён, когда подразумевалось, что запросы будут писать люди, и даже не программисты - и соответственно
Это всё далеко не так, есть куча обоснований, просто вам они может быть и не известны. Раньше у разработчиков были мозги и кугозор в CS, каждый второй нынешний быдлокодер не рвался писать свой велосипед, а мыл посуду в каком-нибудь притоне.
> запросы пытались сделать похожими на выражения английского языка.
Да это же просто чушь. Какая в SQL похожесть на английский язык? Ах, да, попробую угадать - жёсткий порядок построения предложений?
> Что до парсинга - я парсер SQL не писал, так что в чем там проблемы не знаю - однако HandlerSocket за счет отказа от SQL-синтаксиса дает приличный выигрыш.
Потому что HandlerSocket не предоставляет такой же функциональный эквивалент как и SQL. Мягко говоря, довольно глупо приводить такой аргумент против SQL.
Запросы SQL включают гораздо более обширную логику и её нужно анализировать. Как я писал выше, в SQL может уходить время только на анализ уже распарсенного выражения - связывание имён с объектами СУБД, оптимизация, выбор плана и т.п. В HS это всего нет просто потому, что HS ничего практически делать не умеет.
если бы можно было пихать кучу where и прочих в произвольном порядке, а парзер их бы объединял в один — было бы намного проще и удобней.
SELECT ... FROM (...) WHERE;
> SELECT ... FROM (...) WHERE;На третьем вложении оракля обычно перестает оптимизировать запрос целиком. Обычно плохой вариант.
это уже проблемы реализаций, а не языка SQL. Вероятность запутаться оптимизатору в мусорных WHERE о которых выше говорят (т.е. которые можно вставить в любое место) ещё больше.
опрос
почему НЕ нравится sql ?меня например он всем устраивает, на скорость он в НОРМАЛЬНЫХ программах влиять не должен, читается отлично, пишется быстро.
> опрос
> почему НЕ нравится sql ?
> меня например он всем устраивает, на скорость он в НОРМАЛЬНЫХ программах влиять
> не должен, читается отлично, пишется быстро.Он не нравится потому, что подавляющее большинство большего, чем SELECT * FROM DUAL; никогда не писало.
> Он не нравится потому, что подавляющее большинство большего,
> чем SELECT * FROM DUAL; никогда не писало.Еще он не нравится потому, что подавляющее большинство мыслит таблицы в терминах списков, а выборки в терминах процедур. Хотя реляционные БД построены вокруг множеств, и думать о них нужно исключительно в терминах множеств. Для закоснелого процедурщика это требует вывиха мозга, как и лямбда.
Собсно, нелюбовь к котяткам ВСЕГДА имеет причиной неумение их готовить.
> Собсно, нелюбовь к котяткам ВСЕГДА имеет причиной неумение их готовить.И конечно же любой теоретик в мозгу сможет трансформировать запрос в дисковые операции и понять как же оптимальнее для диска все это потом читать. Аж два раза. Прямо не мозг а пентиум про какой-то. С другой стороны у половины NoSQL баз такой проблемы вообще нет в силу простоты запросов.
Вы имели в виду SQL или реляционные базы? SQL - язык достаточно уродский - как я выше писал, он неудобно генерируется и, похоже, тормозно парсится. Не говоря о том, что в тандарт сразу надо было закладывать разделение структуры запроса и таскаемых им данных (причём ни разу не ограничваясь значениями полей) - тогда никаких инъекций не было бы как класса, а генераци стала бы ещё более удобной.А реляционнные базы - да за что ж их не любить? Отличная штука. Другое дело, что для ряда применений предоставляемые ими гарантии (пресловкутый ACID) избыточны и от части можно отказаться в пользу скорости работы иили удобства репликации. Для других случаев избыточна сама реляционность, так как задача не подразумевает сложной структуры данных. Для третьих (всякие графовые извращения, к примеру) структура данных очень плохо ложится РБД.
Вот что раздражает - так это то, что, как правило, люди не описывают, какими именно критериями они руководствуются, выбирая хранилище. В результате осмысленный, возможно, выбор часто выглядит как дурь фанатика.
> Не говоря о том, что в тандарт сразу надо было закладывать разделение структуры запроса и таскаемых им данных (причём ни разу не ограничваясь значениями полей) - тогда никаких инъекций не было бы как класса, а генераци стала бы ещё более удобной.Сразу в стандарт ничего не закладывают, сначала идут реализации и потом стандарт их догоняет. Особенно если говорить о 70-80, когда пароли принято было хранить плейн текстом.
Связанные переменные (т.е. разделение данных и запроса) в SQL по факту дажно уже есть в нормальных СУБД и есть разделение на уровне протоколов. Ещё тут стоит заметить, что SQL всего лишь стандарт языка запросов, он _не_ может указать _как_ должно реализовываться разделение переменных. А это значит, что API может предоставлять разделение, но внутри, т.е. на уровне коммуницации между СУБД и клиентом, всё равно может быть плейн SQL.
Делать в запросе динамическими не только данные нельзя и по этому поводу уже написано 100500 статей и книг.
Итого, проблема разделения данных и запроса (и SQL инъеккий) это не проблема стандарта и SQL, это проблема реализации СУБД и SQL. Так исторически складывается, что прогресс в СУБД для быдлокодеров доходит позже всех остальных. Ещё это осложняется замечательным ЯП который используется в связке с этой самой замечательнйо СУБД.
И чем же оно кардинально отличается от SQL?
SELECT ... FROM ... WHERE ...
UPDATE ... SET ...
INSERT ...Слегка перекошенный SQL - это не NoSQL