WinnipuhBoobenComпропущено...


Я с опечатками напрямую не работаю . Если вам нужен алгоритм фикса опечаток, то стоит поискать чтото другое.


"Он учитывает и слова синонимы, и слова в разных падежах, и слова с опечатками. "

вопросов больше не имею (ц)

не имейте
:D

DPH3Есть просто какое-то хранилище (если там вообще есть хранилище), адаптированное под одну конкретную (очень-очень узкую) задачу и это задачу, возможно, решающее хорошо (увы, данных мало, проверить качество реализации сложно, да и постановки задачи нет).
При этом ни одна из задач собственно СУБД, похоже, не решается.
Такие движки все пишут, не называя громким словом NoSQL СУБД, по большей части там и писать-то особенно нечего.


Почему узкая специализация ?
Например на базе СУБД можно легко написать форум/твиттер.
С регистрациями пользователей, микроблогами, блекджеком и танцовщицами.

Вот пример работы, вводим сообщение, клацаем "Добавить общее сообщение":
http://booben.com/Net?tags=sqlru,nosql

А вот здесь вынесены запросы по такой СУБД:
http://booben.com/Map

DPH3Хм, все ссылки с http://booben.com/Net?tags=all выдают ошибки, причем разные. Впрочем, понять, а что именно там происходит - почти нереально, какие-то непонятные странички...


По тегу all вы получаете все сообщения со всех веток.
Это всеравно что взять и запросить с sql.ru все сообщения в одной ленте (такого сделать тут нельзя, у меня можно).
Чтобы не смешивать все ветки то прописывается путь, например "sqlru nosql"
и тогда поиск ограничивается этими тегами и отображает сообщения только с этой ветки

DPH3BoobenCom,

А, там сплошные ошибки при попытке сделать запросы. Похоже, код даже не тестируется.

Пример ?

Добавил статью
Постреляционность - Первые шаги

На мой взгляд, проблемы RDBMS на сжатии данных не заканчиваются.
И дальше я стараюсь раскрыть эту тему подробней.
Почему RDBMS фундаментально плохо подходит для решения современных бизнесс задач.

Базы данные мой хлеб примерно 12 лет.
НоуСкл где-то четыре года, но больше аматорски.

А у вас какой опыт ?

Вам что-то известно о нормальных формах в СУБД ?

MasterZivBoobenComДобавил статью
Постреляционность - Первые шаги

На мой взгляд, проблемы RDBMS на сжатии данных не заканчиваются.
И дальше я стараюсь раскрыть эту тему подробней.
Почему RDBMS фундаментально плохо подходит для решения современных бизнесс задач.

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

В моем эксперименте РСУБД проиграла где-то в 15ть раз.
Если вы видите за счет чего РСУБД может сжать данные и был большой опыт с сжатием данных,
а главное есть понимание за счет какой природы данных их можно ужать - то напишите подробно.

MasterZivnosql2Предлагается вашему вниманию сравнительный обзор
хранения данных в двух разных системах

http://blog.pikosec.com

Прочитал высстатью до конца.

Всё ясно уже после этих слов:

автор. Почему так происходит – рассмотрим на простом примере. База данных состоит из двух таблиц. В первой таблице хранятся заказы покупателей на товары. Во второй таблице хранятся названия и адресса магазинов, в которых производятся продажи. Связь между таблицами многие к одному. Тоесть многие покупатели делают покупки в одном магазине. У нас простая и логичная модель данных. Но все меняется, если какой-нибудь магазин сменит адресс .

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

P.S. Я как ни странно не против NoSQL, я против псевдонаучных говностатей в сети.

Я бы поубавил на пол оборота эмоциональность высказываний. В основном они говорят о культуре и опыте не того о ком говорят, а о том, кто потеряв всякую надежду конструктивно поддерживать разговор срывается на такие опусы как выше.
Если есть проблемы с пониманием того, что написано в статьях, не стоит расстраиваться. Пускай отвечают только те люди, которые с этим работают и у которых есть опыт и которым есть что написать. Я никуда не спешу, если нужно будет подождать таких людей, то я подожду.

Alexey TominХотя вряд ли - сила NoSQL именно что в заточенности под конкретное решение. Как любое узкоспециальное решение- оно побеждает универсальные.

+1

scfДа, уровень статей низковат.

Они, по сути, вытаскивают узкие аспекты, в которых NoSQL имеет явное преимущество, и показывают их. Проблема же в том, что проблема выбора СУБД должна решаться комплекснои на любой вопрос "а что, если" должен заранее быть ответ.

Пример: А что если нам все-таки нужны транзакции? А что если есть случаи, когда eventual consistency не подходит? А что мы будем делать с рассинхронизацией дублирующихся данных ? А что если выйдет новая версия, а у нас на ней все перестанет работать?

Вот. Вот!
Вы уже на правильном пути, поэтому я готов подвести вас к следующей провокационной мысли.
Итак, я утверждаю что:

А. Дубли это хорошо. Ибо дубли это мать историчности и отец подробный логов. (От чего задыхается современный бизнесс, и это я пишу в своей статье)

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

В. СУБД может иметь свои "аппаратные" возможности для сжатия информации (в 100 и более раз, в этом нет ничего удивительного при правильном подходе к природе данных) и хранить данные даже компактней чем реляционные модели.

Alexey TominГлавная Ваша ошибка описывается одним словом- "Постреляционность". Так же когда-то думали апологеты ооп-субд.

В моем понимании постреляционность это не ООП, а скорей документоориентированые хранилища с аппаратной поддержкой историчности.