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

"Создатели 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 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 on 30-Июл-11, 13:05
А какой практический смысл введения UnQL?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."	+/–
	Сообщение от Vitold S 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 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 | Индекс форумов | Темы | Пред. тема | След. тема