Здравствуйте, gandjustas, Вы писали:
G>Неверно, объект это то что имеет Identity в первую очередь. Все в базе SQL Server имеет стурктурную эквивалентность.
Wiki: Объект (программирование) — некоторая сущность в виртуальном пространстве, обладающая определённым состоянием и поведением, имеет заданные значения свойств (атрибутов) и операций над ними (методов).
Тут мы имеем объект и методы работы с ним.
G>Поэтому не объект. Думаешь что-нить принципиально изменилось бы если бы писали GetLevel(HIERARCHYID id)?
Нет.. Это одна из ранних разновидностей ООП...
AAV>>Проблема в том что NoSQL глубоко залез в современные RDBMS. Или они в него залезли. В общем любой NoSql это просто сильно обрезанный заоптимизированный RDBMS, и если его расширять то мы получим RDBMS, и наоборот если уменьшать и оптимизировать доступ до RDBMS можно получить NoSql. Чем в общем не гнушаются производители RDBMS всовывая в себя элементы NoSql... G>Большего бреда не читал никогда.
А вы почитайте и подумайте. А прежде всего скажите нам, что по вашему RDBMS, а что NoSql...
Здравствуйте, ArhAngelVezel, Вы писали:
AAV>Здравствуйте, gandjustas, Вы писали:
G>>Неверно, объект это то что имеет Identity в первую очередь. Все в базе SQL Server имеет стурктурную эквивалентность. AAV>Wiki: Объект (программирование) — некоторая сущность в виртуальном пространстве, обладающая определённым состоянием и поведением, имеет заданные значения свойств (атрибутов) и операций над ними (методов). AAV>Тут мы имеем объект и методы работы с ним.
"Состояние и поведение" слова ни о чем. Так объектами можно вообще все назвать, и целые числа тоже.
Нужен критерий отделения объектов от не-объектов. Основной критерий это наличие Identity, которого как раз БД нету и не будет.
G>>Поэтому не объект. Думаешь что-нить принципиально изменилось бы если бы писали GetLevel(HIERARCHYID id)? AAV>Нет.. Это одна из ранних разновидностей ООП...
Ну тогда весь SQL это ООП язык.
Бред короче.
AAV>>>Проблема в том что NoSQL глубоко залез в современные RDBMS. Или они в него залезли. В общем любой NoSql это просто сильно обрезанный заоптимизированный RDBMS, и если его расширять то мы получим RDBMS, и наоборот если уменьшать и оптимизировать доступ до RDBMS можно получить NoSql. Чем в общем не гнушаются производители RDBMS всовывая в себя элементы NoSql... G>>Большего бреда не читал никогда. AAV>А вы почитайте и подумайте. А прежде всего скажите нам, что по вашему RDBMS, а что NoSql...
Берем существующие хранилища и смотрим на них.
Со стороны SQL у нас MS SQL Server, oracle, DB2, mysql, postgres, firebird
Со стороны NoSQL: couchdb, mongodb, cassandra, redis, raven
Классифицировать алгоритмы не буду, они не зависят от хранилища.
M>>>>>С NoSQL что еще плохо — то, что этот buzzword объял слишком разные системы, предназначенные для слишком разных нужд. То есть и на всю голову шизанутая Cassandra — это NoSQL и любое key-value хранилище — тоже NoSQL. F>>>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?
G>>>А где его достаточно? Таких задач исчезающе мало.
M>>memcached, который некоторые заменяют redis'ом, например G>Те NoSQL это не более чем распределенный кеш?
Тек, которые key-value store — по сути, да
M>>вообще, все можно свести к понятию «ключ-значение» при условии, что «значение» может быть достаточно сложным G>Да, тогда станет вопрос о том как получать список нужных ключей. Собственно язык SQL дает ответ на этот вопрос, а различные NoSQL хранилища — нет.
Вообще-то, отвечают. Но кадый — по-разному.
G>Полнотекстовым индеском все не заменишь, а вручную создавать индексы под каждый запрос — как то слишком круто.
Можно и не создавать
NoSQL — это не только kv-store И в этом проблема — так как каждый под NoSQL подразумевает что-то свое.
M>>тот же couchdb, кторый весь хайп и начал, по сути, тоже есть ничто иное, как «ключ-значение». Только значение — это документ произвольной форы, который можно скармливать в map/reduce для получения плюшек и девиц (или домомучительниц — это как кому повезет ) G>Ну кучадб используется в очень малом количестве проектов. StackOverflow на нем не сделаешь.
Сделаешь StackOverflow — очень легкий с точки зрения логики сайт. На CouchDB ляжет на раз Только не надо У CouchDB есть свои проблемы.
Здравствуйте, gandjustas, Вы писали:
G>"Состояние и поведение" слова ни о чем. Так объектами можно вообще все назвать, и целые числа тоже.
В SmallTalk так и есть ...
G>Со стороны SQL у нас MS SQL Server, oracle, DB2, mysql, postgres, firebird G>Со стороны NoSQL: couchdb, mongodb, cassandra, redis, raven
G>Классифицировать алгоритмы не буду, они не зависят от хранилища.
А вот и нет:
couchdb, mongodb — это документоорентированные базы
cassandra — это столбцоорентированная база
redis — это key-value орентированная база.
Здравствуйте, Mamut, Вы писали:
M>>>тот же couchdb, кторый весь хайп и начал, по сути, тоже есть ничто иное, как «ключ-значение». Только значение — это документ произвольной форы, который можно скармливать в map/reduce для получения плюшек и девиц (или домомучительниц — это как кому повезет ) G>>Ну кучадб используется в очень малом количестве проектов. StackOverflow на нем не сделаешь.
M>Сделаешь StackOverflow — очень легкий с точки зрения логики сайт. На CouchDB ляжет на раз Только не надо У CouchDB есть свои проблемы.
Да ну?
Не удалось ни тут
Здравствуйте, ArhAngelVezel, Вы писали:
AAV>Здравствуйте, gandjustas, Вы писали:
G>>"Состояние и поведение" слова ни о чем. Так объектами можно вообще все назвать, и целые числа тоже. AAV>В SmallTalk так и есть ...
А толку?
G>>Со стороны SQL у нас MS SQL Server, oracle, DB2, mysql, postgres, firebird G>>Со стороны NoSQL: couchdb, mongodb, cassandra, redis, raven
G>>Классифицировать алгоритмы не буду, они не зависят от хранилища. AAV>А вот и нет: AAV>couchdb, mongodb — это документоорентированные базы AAV>cassandra — это столбцоорентированная база AAV>redis — это key-value орентированная база.
Так это все и есть NoSQL.
AAV>А в первой строчке у вас одни RDBMS...
Именно.
Здравствуйте, noetic, Вы писали:
N>netch80 спрашивал именно о целесообразности такой укладки. просто указал на правильный акцент в вопросе
Так вот я и спрашиваю, в чем его проблема? вот это — правильный акцент.
Здравствуйте, netch80, Вы писали:
N>Где тут "не ложится"? Тут неадекватность, неэффективность, громоздкость укладки.
Переводя на русский — это и есть "не ложится". =)
N>Возвращаюсь к исходному. Я привёл пример задачи. Чуть обобщу: есть key-value хранилище с иерархией ключей. Операции — выборка по конкретному ключу, выборка поддерева от одной точки, добавление/замена/удаление по ключу, удаление поддерева. То есть вообще ничего хитрого.
В Реляционках для этого давно есть специальные типы данных. А до этих типов данных было несколько разнообразных решений в зависимости от конкретного сценария, так что не вижу тут никакой проблемы =)
Здравствуйте, IB, Вы писали:
N>>Предложи метод укладки, а я оценю его адекватность для наших задач. IB>Ну, не читать же мне тут тебе ликбез по SQL-ю? =) Уложить в него можно все и это строго математически доказано. )
Ага. Только в заметном числе случаев у нас получается унылое Г. К примеру, в достаточно стандартной задаче представления строки с переменным числом столбцов.
Здравствуйте, gandjustas, Вы писали:
G>>>С NoSQL полностью аналогично. По факту лучше NoSQL вообще не использовать как основное хранилище. N>>Ты опять используешь недоказанные постулаты. А хотелось бы увидеть доказательства. G>Чуть менее чем все NoSQL базы (я имею ввиду именно хранилища) не имеют ACID транзакций. В итоге для надежного хранения данных в них надо поднимать неслабую инфраструктуру так сказать upfront, еще до того как реально будет сделано что-то нужное.
А тут как бы полный CAP. На практике ты в высоконагруженных системах можешь выбрать только одно из двух — Availability или Consistency. Partition Tolerance — он обязательный.
Здравствуйте, Cyberax, Вы писали:
C>Ага. Только в заметном числе случаев у нас получается унылое Г.
Ага, в _не_ заметном числе случаев, и если руки под унылое Г. заточены. =)
C> К примеру, в достаточно стандартной задаче представления строки с переменным числом столбцов.
У строки нет столбцов
Здравствуйте, IB, Вы писали:
C>>Ага. Только в заметном числе случаев у нас получается унылое Г. IB>Ага, в _не_ заметном числе случаев, и если руки под унылое Г. заточены. =)
Ну да. Если понасиловать РБД, то часто можно научить её немного работать как NoSQL.
C>> К примеру, в достаточно стандартной задаче представления строки с переменным числом столбцов. IB>У строки нет столбцов
Ок. "Способ представления кортежей с произвольным числом элементов" тебя устроит?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>>>С NoSQL полностью аналогично. По факту лучше NoSQL вообще не использовать как основное хранилище. N>>>Ты опять используешь недоказанные постулаты. А хотелось бы увидеть доказательства. G>>Чуть менее чем все NoSQL базы (я имею ввиду именно хранилища) не имеют ACID транзакций. В итоге для надежного хранения данных в них надо поднимать неслабую инфраструктуру так сказать upfront, еще до того как реально будет сделано что-то нужное. C>А тут как бы полный CAP. На практике ты в высоконагруженных системах можешь выбрать только одно из двух — Availability или Consistency. Partition Tolerance — он обязательный.
Мы уже это проходили. 90% проектов не столкнутся с высоконагруженными распределенными системами. А те которые столкнутся будут применять совершенно аналогичные подходы независимо от того какое хранилище.
Только для NoSQL хранилищ это обязательно надо делать, а для SQL — по мере необходимости.
Здравствуйте, gandjustas, Вы писали:
C>>А тут как бы полный CAP. На практике ты в высоконагруженных системах можешь выбрать только одно из двух — Availability или Consistency. Partition Tolerance — он обязательный. G>Мы уже это проходили. 90% проектов не столкнутся с высоконагруженными распределенными системами. А те которые столкнутся будут применять совершенно аналогичные подходы независимо от того какое хранилище.
А те которые не столкнутся — нам и неинтересны.
G>Только для NoSQL хранилищ это обязательно надо делать, а для SQL — по мере необходимости.
Ну так никто и не просит применять NoSQL сразу везде.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>А тут как бы полный CAP. На практике ты в высоконагруженных системах можешь выбрать только одно из двух — Availability или Consistency. Partition Tolerance — он обязательный. G>>Мы уже это проходили. 90% проектов не столкнутся с высоконагруженными распределенными системами. А те которые столкнутся будут применять совершенно аналогичные подходы независимо от того какое хранилище. C>А те которые не столкнутся — нам и неинтересны.
Нам как раз интересны насущные проблемы, а не теоретические. странно что тебе ровно наоборот.
G>>Только для NoSQL хранилищ это обязательно надо делать, а для SQL — по мере необходимости. C>Ну так никто и не просит применять NoSQL сразу везде.
Ну да, потом распределенный кеш сделать для оптимизации.