The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Создатели CouchDB и SQLite представили UnQL, аналог SQL для систем NoSQL

30.07.2011 09:51

Компания Couchbase, развивающая такие системы, как CouchDB, Memcached и Membase, анонсировала создание нового языка запросов - UnQL (Unstructured Data Query Language), напоминающего SQL, но ориентированного на работу с неструктурированными данными. Проект выполнен совместными усилиями Ричарда Гиппа (Richard Hipp), создателя SQLite, и Дэмиена Каца (Damien Katz), основателя проекта CouchDB. Разработка передана сообществу в виде общественного достояния.

Основной целью разработки было создание для NoSQL-систем привычного и стандартизованного языка для определения и манипулирования данными. UnQL выступает в роли неструктурированного эквивалента SQL и призван заполнить образовавшуюся нишу, связанную с отсутствием единой формы задания модели данных и языка запросов, которые могли бы стать стандартом для нереляционных баз данных, манипулирующих неструктурированными данными в формате ключ/значение.

UnQL имеет SQL-подобный синтаксис и поддерживает такие команды, как SELECT, DELETE, INSERT и UPDATE, что делает новый язык запросов привычным для большинства разработчиков. Тем не менее, в отличие от SQL, UnQL обладает рядом расширенных возможностей, позволяющих манипулировать и выбирать информацию в хранилищах документов со сложной и неоднородной структурой. Для определения представления документов используется формат JSON (JavaScript Object Notation).

Вместо таблиц UnQL манипулирует коллекциями разнородных документов, структура которых жестко не определена и может варьироваться в разных документах (структура документа задается в самом документе, общая схема данных отсутствует). Для создания коллекций по аналогии с SQL-выражением "CREATE/DROP TABLE" используется "CREATE/DROP COLLECTION", при этом коллекция служит для логического разделения различных наборов документов.

Присутствующие в каждом документе поля определяются через JSON, в простейшем случае JSON-представление может состоять из одной строковой или числовой переменной. Каждое из таких полей может фигурировать в блоке "WHERE" запроса SELECT, при этом запрос коснется только документов, в которых определены данные поля. В запросе также могут быть заданы критерии сортировки (ORDER BY), группировки (GROUP BY, HAVING), ограничения размера выборки (LIMIT... OFFSET) и объединения (UNION, INTERSECT, EXCEPT). Поддерживается создание индексов (CREATE INDEX) и использование атомарных транзакций (BEGIN, ROLLBACK, COMMIT). Операции добавления, удаления и изменения данных (INSERT, DELETE, UPDATE) могут выполняться как в синхронном, так и в асинхронном (возвращение управления не дожидаясь фактического выполнения) режимах.

  1. Главная ссылка к новости (http://www.couchbase.com/press...)
  2. OpenNews: Ведущие поставщики NoSQL-баз CouchOne и Membase объявили о слиянии
  3. OpenNews: Проект NewSQL призван решить проблемы, с которыми столкнулся Facebook, используя MySQL
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/31346-nosql
Ключевые слова: nosql, unql
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (75) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 12:14, 30/07/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Типа чтобы вместо SQL иньекций были UnQL иньекции? Вообще-то главные плюсы nosql это то что не надо тратить время на разбор синтаксиса каких-то там языков и нет риска что какой-то урод заиньектит команды. Спасибо, но исправлять эти два "недостатка" не требуется.
     
     
  • 2.2, VoDA (ok), 12:18, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • –2 +/
    injection это косяк языков работающих с СУБД, но не самих СУБД. Запретить в драйвере PHP делать конкатенацию WHERE, заставить работать через связанные переменные и инжекции исчезнут как класс =)))
     
     
  • 3.16, Онаним (?), 16:58, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В драйвере PHP? ага, хорошо сказал
     
  • 3.18, Аноним (-), 17:26, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Попробуйте допустить такой косяк в базе ключ-значение? :) Хоть на пыхпыхе хоть на чем там вам угодно. Как бы там фича в том что тип операции задается в коде, а передаваемые параметры ну никак не изменят тип операции. Т.е. допустим поиск значения ну никак не превратиться в дроп таблицы. Это довольно ощутимый плюс: иньектить становится просто нечего и незачем. Чем проще конструкция тем она надежнее. Гольный key-value хрен сломаешь.
     
     
  • 4.44, Etch (?), 19:27, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Там, где есть 'WHERE', всегда можно вставить ' OR своё условие'.
     
  • 4.85, шо (?), 15:12, 03/08/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    не k-v storage единым жив NoSQL
     
  • 3.36, FSA (??), 18:40, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Откройте для себя mysqli. Используем prepare и bind_param и SQL-injections нам не страшны.
     
     
  • 4.53, DeadLoco (ok), 20:22, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А использовать хранимые процедурки и к ним обращаться - не проще ли? И не эффективней ли, чем в коде каждый раз препарировать запрос, выполняя, как минимум, лишние повторы парсинга кода?
     
     
  • 5.58, klalafuda (?), 21:32, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А использовать хранимые процедурки и к ним обращаться - не проще ли? И не эффективней ли, чем в коде каждый раз препарировать запрос, выполняя, как минимум, лишние повторы парсинга кода?

    Вообще то prepared statements и stored procedures - это как бы ортогональные друг-другу вещи. Как скажем мягкое и фиолетовое. Естественно что независимо от конкретной RDBMS будь то MySQL, Oracle или кто-то другой.

     
  • 2.4, Xasd (ok), 12:59, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > нет риска что какой-то урод заиньектит команды

    этого риска нет в любом случае, если у программиста руки не из Ж растут

    каждый раз когда программист занимается формированием строки "A + B + C" (из нескольких разных компонентов, некоторые из которых константны а некоторые переменны) -- он ЧЁТКО пониает границы за которые могут выходить "A" "B" "C" ...

    ...и не важно что это SQL, или HTML, или SHELL_CMD, или BLAHBLAHBLAH.... принцып везде один и тотже: "ПЕРЕМЕННАЯ-СОСТОВЛЯЮЩАЯ, НАХОДЯЩАЯСЯ ВНУТРИ ПОСТОЯННОЙ СОСТОВЛЯЮЩЕЙ -- ДОЛЖНА БЫТЬ ПЕРЕДАНА В СООТВЕТСТВУЮЩЕМ ВИДЕ, А НЕ ПУТЁМ ПРОСТОЙ ПОДСТАНОВКИ"

    # p.s.: я НЕ имею ввиду что программисту нужно *вручную* каждый раз формировать "A + B + C".. но понимать как оно формируется -- он просто обязан

     
     
  • 3.23, Аноним (-), 17:42, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Он всегда есть, потому что параметры передаются вместе с самим запросом, юзер на... большой текст свёрнут, показать
     
     
  • 4.80, Aleks Revo (?), 21:36, 31/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Если Вы не знаете, что такое "границы", их проверка и подготовка значений - не делайте голословных заявлений о рисках ;-)

    В случае скуля не приходится ровным счётом ничего "вручную костылить". Начиная от prepared statements, реализуемых драйвером автоматически, заканчивая соответствующими escape-функциями, позволяющими программисту тонко контролировать процесс.

    Если у Вас база получает непроверенные данные - это таки Ваши проблемы, а не проблемы базы.

    Если программера нужно "строить" чтобы он выполнял свою работу, то не пошёл ли такой программер лесом в известном направлении?

    > В key-value базу можно и путем простой подстановки пхать.

    Интересно увидеть пример такой простой подстановки, если типичный интерфейс передачи параметров подобен prepareStatement.

     
     
  • 5.86, Аноним (-), 19:33, 04/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > В случае скуля не приходится ровным счётом ничего "вручную костылить". Начиная от
    > prepared statements, реализуемых драйвером автоматически, заканчивая соответствующими
    > escape-функциями, позволяющими программисту тонко контролировать процесс.

    Автоматизация костылестроения и тюнинг костылей. Шедеврально.

    А в базах ключ-значение в выражении вида value = get(key) вообще облажаться негде. Юзер может пхать как key все что хочет даже. Но это мало ему поможет. И не надо никакого эскейпинга, prepare statement и прочих костылей. Можно влобешник имя пользователя отдать как key без особых рисков. Стоит ли говорить что базы key-value сами по себе просто убойно быстрые, да еще и дополнительно тормозить эскейпингами и prepare statements не надо.

     
  • 2.6, Анон (?), 13:05, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Признаюсь, я никогди не работал с не SQL СУБД, поэтому мне сложно судить нужен ли UnSQL. Но давайте представим, что SQL не стандарт, тогда каждый разработчик (производитель) реляционной СУБД придумывал бы свои язык запросов, и это учитывая то, что сейчас у каждой реляционной СУБД итак есть свои небольшие отклонения от стандарта SQL.
     
     
  • 3.12, anonymous (??), 14:19, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > тогда каждый разработчик (производитель) реляционной СУБД придумывал бы свои язык запросов

    а NoSQL обычно не реляционные. опаньки.

     
  • 3.24, Аноним (-), 17:44, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Признаюсь, я никогди не работал с не SQL СУБД, поэтому мне сложно
    > судить нужен ли UnSQL.

    Да чего уж там, давайте допустим что по другому работать с базами вообще нельзя. Куда уж нам ключ-значение например освоить.Это же думать надо, а не сбагривать десятиэтажный запрос движку, который как-нибудь подразопрется. Слив в 20 раз по производительности и позволив over 9000 возможных атак на базу.

     
     
  • 4.32, Аноним (-), 18:07, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Слив в
    > 20 раз по производительности и позволив over 9000 возможных атак на
    > базу.

    В 20? Относительно CouchDb mapreduce "слив" в 2000 раз на сложных запросах.


     
  • 2.11, anonymous (??), 14:18, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Вообще-то главные плюсы nosql
    > это то что не надо тратить время на разбор синтаксиса каких-то
    > там языков и нет риска что какой-то урод заиньектит команды.

    мда. похапэ на марше. вообще-то, «главные плюсы NoSQL» совсем не в этом. да и вообще, что такое это ваше «NoSQL»? вот HailDB — это подходит? или ещё не кошерно?

     
     
  • 3.25, Аноним (-), 17:48, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Самый кошерный nosql - базы типа ключ-значение. Убойно быстро. И не хакабельно практически. Ну да, единственный недостаток (для быдлокодеров) ровно один: надо думать головой, а не просто наворачивать немеряные select * ..., которые потом всю таблицу на уйму записей при каждом запросе читают :)

    Вообще, sql позволяет наворачивать одним махом конструкции которые потом лопатят всю базу на каждый чих. Чем сильно способствует процветанию быдлокодинга и повышению спроса на мощные сервера, попутно с выбросами CO2 :).

     
     
  • 4.30, Alien (??), 18:00, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > единственный недостаток (для быдлокодеров) ровно один: надо думать
    > головой, а не просто наворачивать немеряные select * ..., которые потом
    > всю таблицу на уйму записей при каждом запросе читают :)

    1. Умные люди стоят денег, а их не так много, и людей и денег.
    2. С усложнением структуры базы требуемая квалификация команды и тестеров,
    как и их стоимость, возрастает геометрически.
    Убогость, она не в технологии, она в головах.
    Есть ниша для реализаций на Berkley DB, но ряд задач на
    нереляцеонных БД удовлетворительно не решить.

     
     
  • 5.87, Аноним (-), 19:41, 04/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так нормальный человек стремится поумнеть Зачем же деградантствовать и полаг... большой текст свёрнут, показать
     
  • 4.38, FSA (??), 18:45, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Самый кошерный nosql - базы типа ключ-значение. Убойно быстро. И не хакабельно
    > практически. Ну да, единственный недостаток (для быдлокодеров) ровно один: надо думать
    > головой, а не просто наворачивать немеряные select * ..., которые потом
    > всю таблицу на уйму записей при каждом запросе читают :)
    > Вообще, sql позволяет наворачивать одним махом конструкции которые потом лопатят всю базу
    > на каждый чих. Чем сильно способствует процветанию быдлокодинга и повышению спроса
    > на мощные сервера, попутно с выбросами CO2 :).

    CO2 вообще уже давно мало кого волнуют. В корпоративном мире уже давно царствует пожирающий ресурсы Java, а о качественном коде уже никто не думает, лишь бы работало и как можно быстрее.

     
     
  • 5.40, anonymous (??), 18:48, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > лишь бы работало и как можно быстрее.

    ну, то есть, лишь бы работало и *писалось как можно быстрее*.

     
  • 5.88, Аноним (-), 19:42, 04/08/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > CO2 вообще уже давно мало кого волнуют.

    Так то от скудоумия. Планета у нас одна. Другой - нет. Засрем - вымрем как мамонты!
    И никакие доллары не помогут.

     

  • 1.3, Аноним (-), 12:46, 30/07/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    интересно как оно все тормозит...
    если есть документооборот с кучей фирм и каждая в своем формате данные предоставляет, то может и есть смысл...
     
  • 1.5, Vitold S (?), 13:05, 30/07/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А какой практический смысл введения UnQL?
     
     
  • 2.7, Vitold S (?), 13:06, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Хотя в принципе наверное глобальный UPDATE или LEFT JOIN коллекций сделать на стороне базы будет быстрее чем в скриптах. Или я ошибаюсь?
     
  • 2.13, anonymous (??), 14:20, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А какой практический смысл введения UnQL?

    привлечение большего количества обезьян.

     
  • 2.17, VoDA (ok), 17:18, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А какой практический смысл введения UnQL?

    переносимость приложений между NoSQL БД, плюс быстрее народ будет въезжать как работать с этими такими странными СУБД

     
     
  • 3.27, Аноним (-), 17:50, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > переносимость приложений между NoSQL БД, плюс быстрее народ будет въезжать как работать
    > с этими такими странными СУБД

    Да, специально обученные обезьяны которые еле освоили синтаксис для даунов придут, и начнут лажать и в UnSQL и начнутся UnSQL иньекции. Как мило. Мало нам sql иньекций, давайте nosql-иньекции стандартизуем :).И что, опять мудохаться с эскейпингом имен пользователей и прочий онанизм? А не пошли бы вы?

     
     
  • 4.69, VoDA (ok), 12:12, 31/07/2011 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> переносимость приложений между NoSQL БД, плюс быстрее народ будет въезжать как работать
    >> с этими такими странными СУБД
    > Да, специально обученные обезьяны которые еле освоили синтаксис для даунов придут, и
    > начнут лажать и в UnSQL и начнутся UnSQL иньекции. Как мило.
    > Мало нам sql иньекций, давайте nosql-иньекции стандартизуем :).И что, опять мудохаться
    > с эскейпингом имен пользователей и прочий онанизм? А не пошли бы
    > вы?

    Чудаки хватит уже недостатки PHP выдавать за общие... или PHP считать единственным правильным языком. В той же Java несколько раз негативно упомянутой инъекции отсутствуют как класс =)

    а мы и ушли на более интересные языки программирования нежели PHP ;)

     
     
  • 5.75, Аноним (-), 18:45, 31/07/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>В той же 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.

     
  • 5.89, Аноним (-), 19:44, 04/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Чудаки хватит уже недостатки PHP выдавать за общие...

    В каком месте я вообще хоть слово про пхп сказал? У вас какие-то личные счеты к пыху?

     
  • 2.84, Pavel Drobushevich (?), 12:47, 03/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А вы пробовали делать выборки данных для какой-нибудь NoSQL? Вот пример как выглядит sql и выборка для MongoDB. Простая задача: посчитать сколько запросов сделал каждый пользователь
    http://yfrog.com/z/kfiwnjp
     

  • 1.8, Аноним (-), 13:11, 30/07/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно, когда они для couchdb  это реализуют?..
     
  • 1.9, gegMOPO4 (ok), 13:15, 30/07/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    UnQL — это SQL для NoSQL, только без SQL.
     
     
  • 2.71, Captain Beefheart (?), 13:22, 31/07/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > UnQL — это SQL для NoSQL, только без SQL.

    Next step NoUnQL?

     
     
  • 3.90, Аноним (-), 19:45, 04/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Next step NoUnQL?

    А потом UnUnSQL? А на какой итерации наступает stack overflow? :)

     

  • 1.10, anonymous (??), 14:15, 30/07/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    потом добавят реляционность, потом жёсткие схемы данных, потом… wait! oh, shi~~~~~~
     
     
  • 2.21, Crazy Alex (ok), 17:38, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Причём берут из реляционных БД худшие черты. Это надо же - SQL взять за образец.
     
     
  • 3.54, DeadLoco (ok), 20:24, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Причём берут из реляционных БД худшие черты.
    > Это надо же - SQL взять за образец.

    А что надо было брать за образец?

     
     
  • 4.59, all_glory_to_the_hypnotoad (ok), 23:52, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Tutorial/Industrial D
     

  • 1.14, Пиу (?), 16:15, 30/07/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    nosql is a joke
    какая разница что в качестве запросов - sql или жабаскрипт?
     
     
  • 2.29, Аноним (-), 17:54, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > nosql is a joke
    > какая разница что в качестве запросов - sql или жабаскрипт?

    NoSQL сами по себе не оперируют ява-скриптом.А из какого языка приедет запрос к базе - вообще не принципиально. И плюс в том что например юзер введя вместо имени alert("db pwned!") нифига не поимеет удаленную базу, в отличие от скуля где это на каждом шагу, по поводу чего процветает постоянное затыкание этой "фичи" костылями и подпорками, защищающими движок бд от добрых пользователей. При том не совсем понятно почему задача обороны движка от юзеров спихана на какого-то стороннего програмера, который в этом может быть не ас а полный ass.

     
     
  • 3.33, Аноним (-), 18:15, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > NoSQL сами по себе не оперируют ява-скриптом.

    Смотря какие CouchDB как раз оперирует. Все донные хранятся в json. Все вычисления(map/reduce) на javascript, конфигурация и тесты тоже. В зависимостях тянет спайдерманки.


     
  • 3.42, Пиу (?), 19:03, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> nosql is a joke
    >> какая разница что в качестве запросов - sql или жабаскрипт?
    > NoSQL сами по себе не оперируют ява-скриптом.А из какого языка приедет запрос
    > к базе - вообще не принципиально. И плюс в том что
    > например юзер введя вместо имени alert("db pwned!") нифига не поимеет удаленную
    > базу, в отличие от скуля где это на каждом шагу, по
    > поводу чего процветает постоянное затыкание этой "фичи" костылями и подпорками, защищающими
    > движок бд от добрых пользователей. При том не совсем понятно почему
    > задача обороны движка от юзеров спихана на какого-то стороннего програмера, который
    > в этом может быть не ас а полный ass.

    "на каждом шагу" - это такая гипербола, литературный оборот, да?
    и вообще эскейпинг спасет отца русской демократии, ага

     
     
  • 4.67, Аноним (-), 10:27, 31/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > и вообще эскейпинг спасет отца русской демократии, ага

    Ты это скажи программистам например vBulletin в котором очередной раз обнаружили не фильтруемое поле, на этот раз Referer.
    Ты предлагаешь проверять все устанавливаемые фреймворки и готовые решения на уязвимости?
    Миллионы строк кода? Правда?


     
  • 4.70, VoDA (ok), 12:15, 31/07/2011 [^] [^^] [^^^] [ответить]  
  • +/

    > "на каждом шагу" - это такая гипербола, литературный оборот, да?
    > и вообще эскейпинг спасет отца русской демократии, ага

    Эскейпинг не нужен - нужен адекватный код работы с СУБД.

     
  • 4.91, Аноним (-), 19:47, 04/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > "на каждом шагу" - это такая гипербола, литературный оборот, да?
    > и вообще эскейпинг спасет отца русской демократии, ага

    По аналогии, можно сначала специально сломать вам ногу а потом рассказать что костыли и гипс - спасут отца русской демократии. И что в них после тренировки можно даже бегать понемногу.

     
  • 2.31, Аноним (-), 18:04, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>nosql is a joke какая разница что в качестве запросов - sql или жабаскрипт?

    А это не вы случайно для Сони сайты писали?

     
     
  • 3.41, Пиу (?), 18:59, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    а у вас подробности взлома, сэр?
     
     
  • 4.65, Аноним (-), 10:19, 31/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    По данным, озвученным на BlackHat, с помощью SQL injection за год взламывается более 10 000 00 сайтов. Инжекции самая распространенная уязвимость, каждая вторая используемая уязвимость - имеет такую природу.
    Вот сами полюбуйтесь LizaMoon(подтверждено что Kиза использует SQL inj):
    http://www.google.com/#sclient=psy&hl=en&q=%22%3Cscript+src%3D
    1 800 000 сайтов.

     
     
  • 5.66, Аноним (-), 10:21, 31/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Ссылка побилась:
    http://goo.gl/H0U9h

     

  • 1.19, Crazy Alex (ok), 17:37, 30/07/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Какая редчайшая чушь...

    1. Реляционные базы, будучи построены на одной и той же теории, могут использовать один и тот же язык (ну, с точностью до извращений/инноваций). NoSQL-базы под собой общей теории не имеют и различаются кардинально. Какой тут, на фиг, стнадартизированный язык, если между ними общего - ровно то, что в базу можно как-то положить данные, и еще как-то их извлечь? Да они для Mongo и Couch - и то компромисс не найдут.

    2. Копировать SQL - это явная ошибка. Язык разрабатывался так, чтобы запросы писали люди (причём даже не программисты). Сейчас, когда большинство запросов генерируетс, а уж непрофессионалы их точно не пишут, синтаксис SQL - дикость, неудобная ни в генерации (а ну давай, собери все части запроса в нужной последовательности, с нужными разделителями и т.д.) ни в парсинге (что отлично видим на примере HandlerSocket). Если уж делать язык - надо его делать удобным для текущих применений,благо это не так сложно.

    3. То же касается JSON. Его неудобно читать, а писать - ещё неудобнее, так как строг излишне. Если не нашли ничего приличнее, то, как минимум, надо использовать его надмнжество, допускающее необязательные запятые перед закрывающей скобкой массива или объекта, задание ключей без кавычек если ключ без пробелов и прочих спецсимволов. И, кстати, запятые между элементами массива/объекта можно вообще сделать необязательными - разбор остаётся абсолютно однозначным. Тогда имеем то, что легко может написать человек, м автоматически генерированный JSON воспринимается корректно.

     
     
  • 2.45, all_glory_to_the_hypnotoad (ok), 19:42, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Нет никаких проблем в парсинге и генерации SQL, есть только проблемы его интерпретирования на уровне СУБД, что от синтаксиса языка никак не зависит.

    Язык типа SQL и сейчас нужен в большей степени для анализа людьми, т.е. всё равно должен быть ньюман-френдли. Кроме дебила программиста и условного ORMа есть кучка DBAшников которые потом эти говнотворения читают переделывают в нормальный вид.

     
     
  • 3.47, anonymous (??), 19:48, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > есть кучка DBAшников которые потом эти гoвнoтворения читают переделывают в
    > нормальный вид.

    и тогда всё ВНИЗАПНА! перестаёт работать.

     
     
  • 4.51, Аноним (-), 20:10, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> есть кучка DBAшников которые потом эти гoвнoтворения читают переделывают в
    >> нормальный вид.
    > и тогда всё ВНИЗАПНА! перестаёт работать.

    Сюрприз - вменяемый ДБА правит так, что SQL-код начинает работать и работать быстро.

    В моей практике был случай, когда косо написанный запрос молотил таблицу в 800 млрд строк (это не опечатка) и работал 48 часов. После вмеяемого переписывания опытным ДБА он стал работать 20 минут. ВНЕЗАПНО! Давая те же самые результаты.

     
     
  • 5.57, DeadLoco (ok), 20:40, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > В моей практике был случай, когда косо написанный запрос молотил таблицу в
    > 800 млрд строк (это не опечатка) и работал 48 часов. После
    > вмеяемого переписывания опытным ДБА он стал работать 20 минут. ВНЕЗАПНО! Давая
    > те же самые результаты.

    В моей практике удавалось путем переписывания запросов сократить время выполнения с 15+ минут до 0.001 сек. Человечек ухитрился соорудить каскад вложенных селектов там, где достаточно было WHERE x AND y AND z...

     
     
  • 6.63, Аноним (-), 06:42, 31/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> В моей практике был случай, когда косо написанный запрос молотил таблицу в
    >> 800 млрд строк (это не опечатка) и работал 48 часов. После
    >> вмеяемого переписывания опытным ДБА он стал работать 20 минут. ВНЕЗАПНО! Давая
    >> те же самые результаты.
    > В моей практике удавалось путем переписывания запросов сократить время выполнения с 15+
    > минут до 0.001 сек. Человечек ухитрился соорудить каскад вложенных селектов там,
    > где достаточно было WHERE x AND y AND z...

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

     
  • 5.77, anonymous (??), 19:06, 31/07/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Сюрприз — вменяемый ДБА правит так, что SQL-код начинает работать и работать
    > быстро.

    вменяемых DBA очень мало, увы. а если DBA пригласили уже *после* того, как набыдлокодили — то во вменяемость верится слабо. потому что сами клиенты совершенно невменяемые, и «профессионала» найдут себе под стать.

     
  • 5.92, Аноним (-), 19:49, 04/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Сюрприз - вменяемый ДБА правит так, что SQL-код начинает работать и работать
    > быстро.

    Сюрприз: базу key-value до уровня скуля затормозить - надо сиииииииильно постараться. Например токийский кабинет возвращает значение по ключу в 1 или 2 дисковые операции. На-ка, тормозни его, DBA.

     
     
  • 6.95, lll (??), 12:57, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    а при чем здесь SQL? вы сравниваете BTREE с Hash-таблицей.
     
  • 3.60, Crazy Alex (??), 02:07, 31/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Основная проблема в генерации SQL - то, что в нём конструкции не могут идти в произвольном порядке. То есть если нам извне пришел запрос, мы так просто на него, скажем, дополнительное условие не наложим - потому что после WHERE может идти какой-нибудь HAVING. Только полностью разбирать, добавлять что надо и снова собирать. Или другой пример - при сборке вместо того, чтобы тупо всё совать в строку, нам надо держать семиэтажную структуру - здесь у нас таблицы, которые пойдут во FROM, там поля для SELECT и так далее. При этом ни малейшего обоснования этого дела нет - просто исторически сложилось с тех времён, когда подразумевалось, что запросы будут писать люди, и даже не программисты - и соответственно запросы пытались сделать похожими на выражения английского языка.

    Что до парсинга - я парсер SQL не писал, так что  в чем там проблемы не знаю - однако HandlerSocket за счет отказа от SQL-синтаксиса дает приличный выигрыш.

     
     
  • 4.61, Crazy Alex (??), 02:08, 31/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Нет никаких проблем то, чо нагенерила софтина, нормализовать в случае надобности для чтения человеком.
     
  • 4.64, all_glory_to_the_hypnotoad (ok), 09:52, 31/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Просто это операция типа конкатенации строк Ну так ни к какому языку такого тип... большой текст свёрнут, показать
     
     
  • 5.78, anonymous (??), 19:09, 31/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    если бы можно было пихать кучу where и прочих в произвольном порядке, а парзер их бы объединял в один — было бы намного проще и удобней.
     
     
  • 6.81, all_glory_to_the_hypnotoad (ok), 21:43, 31/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    SELECT ... FROM (...) WHERE;
     
     
  • 7.82, Прохожий старый анонимус (?), 17:35, 01/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > SELECT ... FROM (...) WHERE;

    На третьем вложении оракля обычно перестает оптимизировать запрос целиком. Обычно плохой вариант.

     
     
  • 8.83, all_glory_to_the_hypnotoad (ok), 00:01, 02/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    это уже проблемы реализаций, а не языка SQL Вероятность запутаться оптимизатору... текст свёрнут, показать
     

  • 1.50, пвваы (?), 20:08, 30/07/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    опрос
    почему НЕ нравится sql ?

    меня например он всем устраивает, на скорость он в НОРМАЛЬНЫХ программах влиять не должен, читается отлично, пишется быстро.

     
     
  • 2.52, Аноним (-), 20:10, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > опрос
    > почему НЕ нравится sql ?
    > меня например он всем устраивает, на скорость он в НОРМАЛЬНЫХ программах влиять
    > не должен, читается отлично, пишется быстро.

    Он не нравится потому, что подавляющее большинство большего, чем SELECT * FROM DUAL; никогда не писало.

     
     
  • 3.55, DeadLoco (ok), 20:31, 30/07/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Он не нравится потому, что подавляющее большинство большего,
    > чем SELECT * FROM DUAL; никогда не писало.

    Еще он не нравится потому, что подавляющее большинство мыслит таблицы в терминах списков, а выборки в терминах процедур. Хотя реляционные БД построены вокруг множеств, и думать о них нужно исключительно в терминах множеств. Для закоснелого процедурщика это требует вывиха мозга, как и лямбда.

    Собсно, нелюбовь к котяткам ВСЕГДА имеет причиной неумение их готовить.


     
     
  • 4.93, Аноним (-), 00:11, 11/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Собсно, нелюбовь к котяткам ВСЕГДА имеет причиной неумение их готовить.

    И конечно же любой теоретик в мозгу сможет трансформировать запрос в дисковые операции и понять как же оптимальнее для диска все это потом читать. Аж два раза. Прямо не мозг а пентиум про какой-то. С другой стороны у половины NoSQL баз такой проблемы вообще нет в силу простоты запросов.

     
  • 2.62, Crazy Alex (??), 02:16, 31/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Вы имели в виду SQL или реляционные базы? SQL - язык достаточно уродский - как я выше писал, он неудобно генерируется и, похоже, тормозно парсится. Не говоря о том, что в тандарт сразу надо было закладывать разделение структуры запроса и таскаемых им данных (причём ни разу не ограничваясь значениями полей) - тогда никаких инъекций не было бы как класса, а генераци стала бы ещё более удобной.

    А реляционнные базы - да за что ж их не любить? Отличная штука. Другое дело, что для ряда применений предоставляемые ими гарантии (пресловкутый ACID) избыточны и от части можно отказаться в пользу скорости работы иили удобства репликации. Для других случаев избыточна сама реляционность, так как задача не подразумевает сложной структуры данных. Для третьих (всякие графовые извращения, к примеру) структура данных очень плохо ложится РБД.

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

     
     
  • 3.68, all_glory_to_the_hypnotoad (ok), 10:55, 31/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Не говоря о том, что в тандарт сразу надо было закладывать разделение структуры запроса и таскаемых им данных (причём ни разу не ограничваясь значениями полей) - тогда никаких инъекций не было бы как класса, а генераци стала бы ещё более удобной.

    Сразу в стандарт ничего не закладывают, сначала идут реализации и потом стандарт их догоняет. Особенно если говорить о 70-80, когда пароли принято было хранить плейн текстом.

    Связанные переменные (т.е. разделение данных и запроса) в SQL по факту дажно уже есть в нормальных СУБД и есть разделение на уровне протоколов. Ещё тут стоит заметить, что SQL всего лишь стандарт языка запросов, он _не_ может указать _как_ должно реализовываться разделение переменных. А это значит, что API может предоставлять разделение, но внутри, т.е. на уровне коммуницации между СУБД и клиентом, всё равно может быть плейн SQL.

    Делать в запросе динамическими не только данные нельзя и по этому поводу уже написано 100500 статей и книг.

    Итого, проблема разделения данных и запроса (и SQL инъеккий) это не проблема стандарта и SQL, это проблема реализации СУБД и SQL. Так исторически складывается, что прогресс в СУБД для быдлокодеров доходит позже всех остальных. Ещё это осложняется замечательным ЯП который используется в связке с этой самой замечательнйо СУБД.

     

  • 1.79, Аноним (-), 20:25, 31/07/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    И чем же оно кардинально отличается от SQL?
    SELECT ... FROM ... WHERE ...
    UPDATE ... SET ...
    INSERT ...

    Слегка перекошенный SQL - это не NoSQL

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру