The OpenNET Project / Index page

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



"Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от opennews (??) on 30-Июл-11, 12:14 
Компания Couchbase, развивающая (http://www.opennet.dev/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
Новость: http://www.opennet.dev/opennews/art.shtml?num=31346

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  –5 +/
Сообщение от Аноним (??) on 30-Июл-11, 12:14 
Типа чтобы вместо SQL иньекций были UnQL иньекции? Вообще-то главные плюсы nosql это то что не надо тратить время на разбор синтаксиса каких-то там языков и нет риска что какой-то урод заиньектит команды. Спасибо, но исправлять эти два "недостатка" не требуется.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  –2 +/
Сообщение от VoDA (ok) on 30-Июл-11, 12:18 
injection это косяк языков работающих с СУБД, но не самих СУБД. Запретить в драйвере PHP делать конкатенацию WHERE, заставить работать через связанные переменные и инжекции исчезнут как класс =)))
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

16. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +1 +/
Сообщение от Онаним on 30-Июл-11, 16:58 
В драйвере PHP? ага, хорошо сказал
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

18. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +1 +/
Сообщение от Аноним (??) on 30-Июл-11, 17:26 
Попробуйте допустить такой косяк в базе ключ-значение? :) Хоть на пыхпыхе хоть на чем там вам угодно. Как бы там фича в том что тип операции задается в коде, а передаваемые параметры ну никак не изменят тип операции. Т.е. допустим поиск значения ну никак не превратиться в дроп таблицы. Это довольно ощутимый плюс: иньектить становится просто нечего и незачем. Чем проще конструкция тем она надежнее. Гольный key-value хрен сломаешь.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

44. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +1 +/
Сообщение от Etch on 30-Июл-11, 19:27 
Там, где есть 'WHERE', всегда можно вставить ' OR своё условие'.
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

85. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +1 +/
Сообщение от шо on 03-Авг-11, 15:12 
не k-v storage единым жив NoSQL
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

36. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от FSA (??) on 30-Июл-11, 18:40 
Откройте для себя mysqli. Используем prepare и bind_param и SQL-injections нам не страшны.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

53. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  –1 +/
Сообщение от DeadLoco (ok) on 30-Июл-11, 20:22 
А использовать хранимые процедурки и к ним обращаться - не проще ли? И не эффективней ли, чем в коде каждый раз препарировать запрос, выполняя, как минимум, лишние повторы парсинга кода?
Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

58. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +2 +/
Сообщение от klalafuda on 30-Июл-11, 21:32 
> А использовать хранимые процедурки и к ним обращаться - не проще ли? И не эффективней ли, чем в коде каждый раз препарировать запрос, выполняя, как минимум, лишние повторы парсинга кода?

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

Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

4. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Xasd (ok) on 30-Июл-11, 12:59 
> нет риска что какой-то урод заиньектит команды

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

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

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

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

23. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Аноним (??) on 30-Июл-11, 17:42 
> этого риска нет в любом случае, если у программиста руки не из Ж растут

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

> -- он ЧЁТКО пониает границы за которые могут выходить "A" "B" "C" ...

При чем тут вообще границы? Проблема скуля в том что он часто работает с внешними не доверяемыми  данными. При том он не делает особых различий между операцией и данными для нее, и позволяет несколько операций в одном запросе. Поэтому без спецмер со стороны программера select из таблицы пользователей легко превращается в например ее дроп или произвольный вызов функционала БД, путем указания имени юзера в стиле того комикса про "little Jonny the tables we call him" ;). Понятно что можно програмера построить, заставить проверять что там ему юзер подсунул и прочая. Тут начинается густое костылирование всякими эскейпами (которые порой мешают жить в легитимных случаях и сажают скорость работы) и соревнование - нащупает ли хакер слабину или нет.

> -- ДОЛЖНА БЫТЬ ПЕРЕДАНА В СООТВЕТСТВУЮЩЕМ ВИДЕ, А НЕ ПУТЁМ ПРОСТОЙ
> ПОДСТАНОВКИ"

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

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

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

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

80. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Aleks Revo email on 31-Июл-11, 21:36 
Если Вы не знаете, что такое "границы", их проверка и подготовка значений - не делайте голословных заявлений о рисках ;-)

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

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

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

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

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

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

86. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Аноним (??) on 04-Авг-11, 19:33 
> В случае скуля не приходится ровным счётом ничего "вручную костылить". Начиная от
> prepared statements, реализуемых драйвером автоматически, заканчивая соответствующими
> escape-функциями, позволяющими программисту тонко контролировать процесс.

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

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

Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

6. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Анон on 30-Июл-11, 13:05 
Признаюсь, я никогди не работал с не SQL СУБД, поэтому мне сложно судить нужен ли UnSQL. Но давайте представим, что SQL не стандарт, тогда каждый разработчик (производитель) реляционной СУБД придумывал бы свои язык запросов, и это учитывая то, что сейчас у каждой реляционной СУБД итак есть свои небольшие отклонения от стандарта SQL.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

12. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  +/
Сообщение от anonymous (??) on 30-Июл-11, 14:19 
> тогда каждый разработчик (производитель) реляционной СУБД придумывал бы свои язык запросов

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

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

24. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Аноним (??) on 30-Июл-11, 17:44 
> Признаюсь, я никогди не работал с не SQL СУБД, поэтому мне сложно
> судить нужен ли UnSQL.

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

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

32. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +1 +/
Сообщение от Аноним (??) on 30-Июл-11, 18:07 
> Слив в
> 20 раз по производительности и позволив over 9000 возможных атак на
> базу.

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


Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

11. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  +/
Сообщение от anonymous (??) on 30-Июл-11, 14:18 
> Вообще-то главные плюсы nosql
> это то что не надо тратить время на разбор синтаксиса каких-то
> там языков и нет риска что какой-то урод заиньектит команды.

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

25. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  +2 +/
Сообщение от Аноним (??) on 30-Июл-11, 17:48 
Самый кошерный nosql - базы типа ключ-значение. Убойно быстро. И не хакабельно практически. Ну да, единственный недостаток (для быдлокодеров) ровно один: надо думать головой, а не просто наворачивать немеряные select * ..., которые потом всю таблицу на уйму записей при каждом запросе читают :)

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

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

30. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  +3 +/
Сообщение от Alien (??) on 30-Июл-11, 18:00 
> единственный недостаток (для быдлокодеров) ровно один: надо думать
> головой, а не просто наворачивать немеряные select * ..., которые потом
> всю таблицу на уйму записей при каждом запросе читают :)

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

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

87. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  +/
Сообщение от Аноним (??) on 04-Авг-11, 19:41 
> 1. Умные люди стоят денег, а их не так много, и людей
> и денег.

Ну так нормальный человек стремится поумнеть. Зачем же деградантствовать и полагать что так и надо?

> 2. С усложнением структуры базы требуемая квалификация команды и тестеров,
> как и их стоимость, возрастает геометрически.

Keep it simple, stupid! Да, конечно, на sql.ru можно найти и пример создания базы с 126 столбцами. Какой-то быдлoкодер решил что если движок может - давайте все в отдельной колонке хранить. Вплоть до цвета шрифта в конкретном месте страницы. Вот только такие продукты обычно тормозные, глюкавые и являют собой решетo.

> Убoгость, она не в технологии, она в головах.

Технология может способствовать убoгим решениям а может наоборот усложнять быдлoкодинг.

> Есть ниша для реализаций на Berkley DB, но ряд задач на
> нереляцеонных БД удовлетворительно не решить.

А может просто не надо чрезмерно наворачивать структуру базы? А то сами же потом и будете лaжаться. Базы типа беркелея заставят намного тщательнее подходить к проектированию структуры базы и запросов. И не то чтобы результат от этого станет хуже.

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

38. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  +/
Сообщение от FSA (??) on 30-Июл-11, 18:45 
> Самый кошерный nosql - базы типа ключ-значение. Убойно быстро. И не хакабельно
> практически. Ну да, единственный недостаток (для быдлокодеров) ровно один: надо думать
> головой, а не просто наворачивать немеряные select * ..., которые потом
> всю таблицу на уйму записей при каждом запросе читают :)
> Вообще, sql позволяет наворачивать одним махом конструкции которые потом лопатят всю базу
> на каждый чих. Чем сильно способствует процветанию быдлокодинга и повышению спроса
> на мощные сервера, попутно с выбросами CO2 :).

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

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

40. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  +/
Сообщение от anonymous (??) on 30-Июл-11, 18:48 
> лишь бы работало и как можно быстрее.

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

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

88. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  –1 +/
Сообщение от Аноним (??) on 04-Авг-11, 19:42 
> CO2 вообще уже давно мало кого волнуют.

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

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

3. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Аноним (??) on 30-Июл-11, 12:46 
интересно как оно все тормозит...
если есть документооборот с кучей фирм и каждая в своем формате данные предоставляет, то может и есть смысл...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Vitold S email on 30-Июл-11, 13:05 
А какой практический смысл введения UnQL?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Vitold S email on 30-Июл-11, 13:06 
Хотя в принципе наверное глобальный UPDATE или LEFT JOIN коллекций сделать на стороне базы будет быстрее чем в скриптах. Или я ошибаюсь?
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

13. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  +/
Сообщение от anonymous (??) on 30-Июл-11, 14:20 
> А какой практический смысл введения UnQL?

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

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

17. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от VoDA (ok) on 30-Июл-11, 17:18 
> А какой практический смысл введения UnQL?

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

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

27. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  –2 +/
Сообщение от Аноним (??) on 30-Июл-11, 17:50 
> переносимость приложений между NoSQL БД, плюс быстрее народ будет въезжать как работать
> с этими такими странными СУБД

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

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

69. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  –2 +/
Сообщение от VoDA (ok) on 31-Июл-11, 12:12 
>> переносимость приложений между NoSQL БД, плюс быстрее народ будет въезжать как работать
>> с этими такими странными СУБД
> Да, специально обученные обезьяны которые еле освоили синтаксис для даунов придут, и
> начнут лажать и в UnSQL и начнутся UnSQL иньекции. Как мило.
> Мало нам sql иньекций, давайте nosql-иньекции стандартизуем :).И что, опять мудохаться
> с эскейпингом имен пользователей и прочий онанизм? А не пошли бы
> вы?

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

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

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

75. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +1 +/
Сообщение от Аноним (??) on 31-Июл-11, 18:45 
>>В той же 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.

Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

89. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Аноним (??) on 04-Авг-11, 19:44 
> Чудаки хватит уже недостатки PHP выдавать за общие...

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

Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

84. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Pavel Drobushevich email on 03-Авг-11, 12:47 
А вы пробовали делать выборки данных для какой-нибудь NoSQL? Вот пример как выглядит sql и выборка для MongoDB. Простая задача: посчитать сколько запросов сделал каждый пользователь
http://yfrog.com/z/kfiwnjp
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

8. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Аноним (??) on 30-Июл-11, 13:11 
Интересно, когда они для couchdb  это реализуют?..
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +5 +/
Сообщение от gegMOPO4 (ok) on 30-Июл-11, 13:15 
UnQL — это SQL для NoSQL, только без SQL.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

71. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +1 +/
Сообщение от Captain Beefheart on 31-Июл-11, 13:22 
> UnQL — это SQL для NoSQL, только без SQL.

Next step NoUnQL?

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

90. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Аноним (??) on 04-Авг-11, 19:45 
> Next step NoUnQL?

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

Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

10. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  +6 +/
Сообщение от anonymous (??) on 30-Июл-11, 14:15 
потом добавят реляционность, потом жёсткие схемы данных, потом… wait! oh, shi~~~~~~
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  –1 +/
Сообщение от Crazy Alex (ok) on 30-Июл-11, 17:38 
Причём берут из реляционных БД худшие черты. Это надо же - SQL взять за образец.
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

54. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  +1 +/
Сообщение от DeadLoco (ok) on 30-Июл-11, 20:24 
> Причём берут из реляционных БД худшие черты.
> Это надо же - SQL взять за образец.

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

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

59. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 30-Июл-11, 23:52 
Tutorial/Industrial D
Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

14. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Пиу on 30-Июл-11, 16:15 
nosql is a joke
какая разница что в качестве запросов - sql или жабаскрипт?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

29. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Аноним (??) on 30-Июл-11, 17:54 
> nosql is a joke
> какая разница что в качестве запросов - sql или жабаскрипт?

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

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

33. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Аноним (??) on 30-Июл-11, 18:15 
> NoSQL сами по себе не оперируют ява-скриптом.

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


Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

42. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Пиу on 30-Июл-11, 19:03 
>> nosql is a joke
>> какая разница что в качестве запросов - sql или жабаскрипт?
> NoSQL сами по себе не оперируют ява-скриптом.А из какого языка приедет запрос
> к базе - вообще не принципиально. И плюс в том что
> например юзер введя вместо имени alert("db pwned!") нифига не поимеет удаленную
> базу, в отличие от скуля где это на каждом шагу, по
> поводу чего процветает постоянное затыкание этой "фичи" костылями и подпорками, защищающими
> движок бд от добрых пользователей. При том не совсем понятно почему
> задача обороны движка от юзеров спихана на какого-то стороннего програмера, который
> в этом может быть не ас а полный ass.

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

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

67. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Аноним (??) on 31-Июл-11, 10:27 
> и вообще эскейпинг спасет отца русской демократии, ага

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


Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

70. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от VoDA (ok) on 31-Июл-11, 12:15 

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

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

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

91. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Аноним (??) on 04-Авг-11, 19:47 
> "на каждом шагу" - это такая гипербола, литературный оборот, да?
> и вообще эскейпинг спасет отца русской демократии, ага

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

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

31. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Аноним (??) on 30-Июл-11, 18:04 
>>nosql is a joke какая разница что в качестве запросов - sql или жабаскрипт?

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

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

41. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Пиу on 30-Июл-11, 18:59 
а у вас подробности взлома, сэр?
Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

65. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Аноним (??) on 31-Июл-11, 10:19 
По данным, озвученным на 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 сайтов.

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

66. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Аноним (??) on 31-Июл-11, 10:21 
Ссылка побилась:
http://goo.gl/H0U9h

Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

19. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +2 +/
Сообщение от Crazy Alex (ok) on 30-Июл-11, 17:37 
Какая редчайшая чушь...

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

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

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

45. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 30-Июл-11, 19:42 
Нет никаких проблем в парсинге и генерации SQL, есть только проблемы его интерпретирования на уровне СУБД, что от синтаксиса языка никак не зависит.

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

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

47. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  +1 +/
Сообщение от anonymous (??) on 30-Июл-11, 19:48 
> есть кучка DBAшников которые потом эти гoвнoтворения читают переделывают в
> нормальный вид.

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

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

51. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  +/
Сообщение от Аноним (??) on 30-Июл-11, 20:10 
>> есть кучка DBAшников которые потом эти гoвнoтворения читают переделывают в
>> нормальный вид.
> и тогда всё ВНИЗАПНА! перестаёт работать.

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

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

Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

57. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  +/
Сообщение от DeadLoco (ok) on 30-Июл-11, 20:40 
> В моей практике был случай, когда косо написанный запрос молотил таблицу в
> 800 млрд строк (это не опечатка) и работал 48 часов. После
> вмеяемого переписывания опытным ДБА он стал работать 20 минут. ВНЕЗАПНО! Давая
> те же самые результаты.

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

Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

63. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  +/
Сообщение от Аноним (??) on 31-Июл-11, 06:42 
>> В моей практике был случай, когда косо написанный запрос молотил таблицу в
>> 800 млрд строк (это не опечатка) и работал 48 часов. После
>> вмеяемого переписывания опытным ДБА он стал работать 20 минут. ВНЕЗАПНО! Давая
>> те же самые результаты.
> В моей практике удавалось путем переписывания запросов сократить время выполнения с 15+
> минут до 0.001 сек. Человечек ухитрился соорудить каскад вложенных селектов там,
> где достаточно было WHERE x AND y AND z...

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

Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

77. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  +1 +/
Сообщение от anonymous (??) on 31-Июл-11, 19:06 
> Сюрприз — вменяемый ДБА правит так, что SQL-код начинает работать и работать
> быстро.

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

Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

92. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  +/
Сообщение от Аноним (??) on 04-Авг-11, 19:49 
> Сюрприз - вменяемый ДБА правит так, что SQL-код начинает работать и работать
> быстро.

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

Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

95. "1"  +/
Сообщение от lll (??) on 05-Дек-17, 12:57 
а при чем здесь SQL? вы сравниваете BTREE с Hash-таблицей.
Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

60. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Crazy Alex (??) on 31-Июл-11, 02:07 
Основная проблема в генерации SQL - то, что в нём конструкции не могут идти в произвольном порядке. То есть если нам извне пришел запрос, мы так просто на него, скажем, дополнительное условие не наложим - потому что после WHERE может идти какой-нибудь HAVING. Только полностью разбирать, добавлять что надо и снова собирать. Или другой пример - при сборке вместо того, чтобы тупо всё совать в строку, нам надо держать семиэтажную структуру - здесь у нас таблицы, которые пойдут во FROM, там поля для SELECT и так далее. При этом ни малейшего обоснования этого дела нет - просто исторически сложилось с тех времён, когда подразумевалось, что запросы будут писать люди, и даже не программисты - и соответственно запросы пытались сделать похожими на выражения английского языка.

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

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

61. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Crazy Alex (??) on 31-Июл-11, 02:08 
Нет никаких проблем то, чо нагенерила софтина, нормализовать в случае надобности для чтения человеком.
Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

64. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 31-Июл-11, 09:52 
> Основная проблема в генерации SQL - то, что в нём конструкции не могут идти в произвольном порядке. То есть если нам извне пришел запрос, мы так просто на него, скажем, дополнительное условие не наложим - потому что после WHERE может идти какой-нибудь HAVING. Только полностью разбирать, добавлять что надо и снова собирать.

Просто это операция типа конкатенации строк? Ну так ни к какому языку такого типа нельзя наложить доп. условие даже если формально можно добавить текст кода в конец выражения. Для корректного результата везде нужно проводить полный синтаксический и логический анализ всего выражения. Это не проблема SQL, а прямое следствие отдалённости требуемого конечного результата от начальной структуры данных.

Т.е. я утверждаю, что не придумаешь такую же функциональную альтернативу без этого недостатка. Это из серии 'выберите любое 2 из 3'

> Или другой пример - при сборке вместо того, чтобы тупо всё совать в строку, нам надо держать семиэтажную структуру - здесь у нас таблицы, которые пойдут во FROM, там поля для SELECT и так далее.

Это от части отражение декларативного характера SQL, а не императивного, где как раз можно всё набросать в кучу. Во-вторых, отражение логики обработки запросов в СУБД и порсто выстроение декларации в логическую линию. И это тру вей.

> При этом ни малейшего обоснования этого дела нет - просто исторически сложилось с тех времён, когда подразумевалось, что запросы будут писать люди, и даже не программисты - и соответственно

Это всё далеко не так, есть куча обоснований, просто вам они может быть и не известны. Раньше у разработчиков были мозги и кугозор в CS, каждый второй нынешний быдлокодер не рвался писать свой велосипед, а мыл посуду в каком-нибудь притоне.

> запросы пытались сделать похожими на выражения английского языка.

Да это же просто чушь. Какая в SQL похожесть на английский язык? Ах, да, попробую угадать - жёсткий порядок построения предложений?  

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

Потому что HandlerSocket не предоставляет такой же функциональный эквивалент как и SQL. Мягко говоря, довольно глупо приводить такой аргумент против SQL.

Запросы SQL включают гораздо более обширную логику и её нужно анализировать. Как я писал выше, в SQL может уходить время только на анализ уже распарсенного выражения - связывание имён с объектами СУБД, оптимизация, выбор плана и т.п. В HS это всего нет просто потому, что HS ничего практически делать не умеет.

Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

78. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  +/
Сообщение от anonymous (??) on 31-Июл-11, 19:09 
если бы можно было пихать кучу where и прочих в произвольном порядке, а парзер их бы объединял в один — было бы намного проще и удобней.
Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

81. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 31-Июл-11, 21:43 
SELECT ... FROM (...) WHERE;
Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

82. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  +/
Сообщение от Прохожий старый анонимус on 01-Авг-11, 17:35 
> SELECT ... FROM (...) WHERE;

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

Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

83. "Создатели CouchDB и SQLite представили UnQL, аналог SQL..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 02-Авг-11, 00:01 
это уже проблемы реализаций, а не языка SQL. Вероятность запутаться оптимизатору в мусорных WHERE о которых выше говорят (т.е. которые можно вставить в любое место) ещё больше.
Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

50. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от пвваы on 30-Июл-11, 20:08 
опрос
почему НЕ нравится sql ?

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

52. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +1 +/
Сообщение от Аноним (??) on 30-Июл-11, 20:10 
> опрос
> почему НЕ нравится sql ?
> меня например он всем устраивает, на скорость он в НОРМАЛЬНЫХ программах влиять
> не должен, читается отлично, пишется быстро.

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

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

55. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  –1 +/
Сообщение от DeadLoco (ok) on 30-Июл-11, 20:31 
> Он не нравится потому, что подавляющее большинство большего,
> чем SELECT * FROM DUAL; никогда не писало.

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

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


Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

93. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Аноним (??) on 11-Авг-11, 00:11 
> Собсно, нелюбовь к котяткам ВСЕГДА имеет причиной неумение их готовить.

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

Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

62. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Crazy Alex (??) on 31-Июл-11, 02:16 
Вы имели в виду SQL или реляционные базы? SQL - язык достаточно уродский - как я выше писал, он неудобно генерируется и, похоже, тормозно парсится. Не говоря о том, что в тандарт сразу надо было закладывать разделение структуры запроса и таскаемых им данных (причём ни разу не ограничваясь значениями полей) - тогда никаких инъекций не было бы как класса, а генераци стала бы ещё более удобной.

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

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

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

68. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 31-Июл-11, 10:55 
> Не говоря о том, что в тандарт сразу надо было закладывать разделение структуры запроса и таскаемых им данных (причём ни разу не ограничваясь значениями полей) - тогда никаких инъекций не было бы как класса, а генераци стала бы ещё более удобной.

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

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

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

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

Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

79. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Аноним (??) on 31-Июл-11, 20:25 
И чем же оно кардинально отличается от SQL?
SELECT ... FROM ... WHERE ...
UPDATE ... SET ...
INSERT ...

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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