Релиз MongoDB 2.2.0

Нет. Потому что в общим случае, как и программы, так и форматы данных, с которыми они работают полностью детерминированны, и реляционки тут лучше всего вписываются.

Спроси у Крона, сколько раз он успевает матюкнуться, прежде чем выполнится очередная команда ALTER TABLE на его авиабазе...

В нашей дискуссии SQL противопоставляется NoSQL, а потому речь идёт не отдельно о языке SQL, а о РСУБД в целом, потому ACID, как и остальные свойства РСУБД, подразумеваются по-умолчанию.

Они для разных почти не перекрывающихся областей задач

Да-да, то-то каждая вторая руби-хоумпага пытается на монго взлететь.

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

Да. Но только не нужно забывать о том, что «You are not Twitter», и с вероятностью 99% тебе не нужен NoSQL.

Спроси у Крона, сколько раз он успевает матюкнуться, прежде чем выполнится очередная команда ALTER TABLE на его авиабазе...

Он ССЗБ со своим mysql.

Да. Но только не нужно забывать о том, что «You are not Twitter», и с вероятностью 99% тебе не нужен NoSQL.

Чем SQL лучше чем NoSQL для моего веб сайта? Mongo, как минимум, дает легко изменять схему базы (ее там просто нет или почти нет, есть только индексы по нужным полям).

P.S. Twitter уже научился деньги зарабатывать или он до сих пор убыточный.

Лучше осваивай SQL, noSQL базы очень специфичны, и используются реже, а SQL стандартизирован, и ты сможешь работать практически с любой реляционной СУБД. К тому же SQL более продвинут.

Чем SQL лучше чем NoSQL для моего веб сайта?

Для твоего сраного сайта хватит sqlite, гарантирую это.

Но только не нужно забывать о том, что «You are not Twitter», и с вероятностью 99% тебе не нужно изучать незнакомый инструмент только для того, чтобы решить вопрос с масштабированием.

Так будет корректнее, и выводы получатся слегка иные.

Mongo, как минимум, дает легко изменять схему базы

Какой веский аргумент

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

Так будет корректнее, и выводы получатся слегка иные.

Честно говоря, не вижу различия в выводах.

Mongo, как минимум, дает легко изменять схему базы

У тебя сайт уже размером с авиабазу крона?

Twitter уже научился деньги зарабатывать или он до сих пор убыточный.

Это имеет отношение к твоему веб-сайту?

Спроси у Крона, сколько раз он успевает матюкнуться, прежде чем выполнится очередная команда ALTER TABLE на его авиабазе...

Минут до 40 на форумной БД :) Я уже просто тупо стал на это время весь народ отправлять на запасной LiveStreet-ресурс под другой БД.

MySQL, модификация и непрерывный онлайн никак не совместимы. Только два из трёх требований :)

У меня настроение позанудствовать, поэтому я буду продолжать напоминать о том, что sql && acid понятия в общем-то ортогональные. Недаром же гугл sql (или его подмно;ество) в своем appengine прикрутил поверх своей big table.

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

Если специалист освоил и монгу, и постгрес, то для написания сайта, скорее всего, предпочтёт монгу, несмотря на то, что масштабирование ему не нужно.

Как интересно. И почему же?

А потом ты еще спрашиваешь, почему тебя называют говнокодером.

Если специалист освоил и монгу, и постгрес, то для написания сайта, скорее всего, предпочтёт монгу, несмотря на то, что масштабирование ему не нужно.

Я специалист, освоил и монго, и кауч. Авторитетно заявляю, NoSql нужен только для очень (преочень) узкого круга задач. Если его везде пихать как замену реляционкам, кроме резкой боли в жопе ничего не получается.

Ещё раз. Мы говорим об РСУБД, а не языке SQL. BigTable не стала реаляционной базой, несмотря на добавленную поддержку языка запросов SQL.

А потом ты еще спрашиваешь, почему тебя называют говнокодером.

Ты опять бредишь.

Mongo, как минимум, дает легко изменять схему базы

У тебя сайт уже размером с авиабазу крона?

Twitter уже научился деньги зарабатывать или он до сих пор убыточный.

Это имеет отношение к твоему веб-сайту?

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

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

Можешь подробнее и с примерами.

Авторитетно заявляю, NoSql нужен только для очень (преочень) узкого круга задач.

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

Если его везде пихать как замену реляционкам,

Пилить молотком действительно неудобно.

Ты можешь продолжать отвечать вопросом на вопрос и игнорировать вопросы тебе

Релиз MongoDB 2.2.0 (комментарий)

Релиз MongoDB 2.2.0 (комментарий)

а я когда заканчивается конструктив просто заканчиваю общение.

Какая потеря.

Можешь подробнее и с примерами.

Далеко не всегда можно всю связанную информацию поместить в один документ. Отсюда сразу две проблемы, целостность при обновлении документов и выборка связанных документов.

Звучит несколько обще, да, но с этим сталкиваешься очень быстро при попытке натянуть на носкуль ветвистую предметную область. Такие дела.

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

Очевидно, что проектировать структуры данных под монгу нужно иначе, ежели под РСУБД (к примеру, не нужно бояться денормализации, и сущности удобнее выделять, отталкиваясь от операций над ними, а не пытаться переносить «физическую» структуру). С опытом придёт понимание, главное, не сдаваться после первой же неудачи :). Сам тоже преодолевал некие психологические барьеры, когда вникал - действительно, кажется, что отсутствие схемы данных - это разгильдяйство, а не фича, и вызывает ощущение неконтролируемости. Потом постепенно становится ясно, что смотреть реаляционным взглядом на монгу не нужно, и дела сразу двигаются в гору :).

Уверен, когда-нибудь твои прыщи перестанут тебя беспокоить. А я половое созревание уже давно пережил :).

Если специалист освоил и монгу, и постгрес, то для написания сайта, скорее всего, предпочтёт монгу

Если этот специалист предпочтёт монгу, то вероятно, он еще не сделал домашнее задание по алгебре.

А потом ты еще спрашиваешь, почему тебя называют говнокодером.

Где его называют говнокодером?

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

Потом вышел из запоя?

Прыщи это состояние души, с половым взрослением никак не связана.

Задача: реализовать аккаунтинг на монго. Есть иерархия счетов, есть проводки, есть транзакции, в одной транзацкии может быть несколько проводок, каждая проводка затрагивает два счета (откуда/куда). Нужна отчетность по срезу счетов за произвольный интервал времени, баланс на начало, дебет, кредит и баланс на конец.

Дерзай. То, на что уходит один вечер за постгресом, оборачивается неделей проектирования под NoSQL и в итоге работает медленней и с кучей костылей.

Сейчас он скажет, что конкретно под эту задачу Монго не совсем подходит, и предложит реализовать систему комментариев/твиттер.

Твоя агрессия совершенно не даёт тебе слышать собеседника. Мне кажется, я назвал отчёты как раз той самой областью, для которой скорее подойдёт РСУБД.

Нет, я предложу не развешивать ярлыки «за монго» и «против монго», и предложу расширять кругозор, а не хвататься за свои знания как за единственный оплот надёжности в столь динамичном мире :).

Ну так ты сам навесил ярлык монго, что это практически панацея -
(Релиз MongoDB 2.2.0 (комментарий))

Ну вот допустим я хочу сделать сайт - пользователи размещают объявления (любые, допустим аренда квартир). Стоимость 1 объявления 1 руб. Мне для этой задачи монго взять?

Я уверен, что ты можешь беседовать со мной без моего участия :). Ты в любых словах видишь то, что ожидаешь.

Мне кажется, я назвал отчёты как раз той самой областью, для которой скорее подойдёт РСУБД.

Какие же это отчеты? Здесь всего три сущности без many-to-many отношений с простыми (предельно простыми) выборками. Ты отчетов не видел с джойнами на двадцать таблиц или портянки, которые генерит 1C. Очень жаль что ты так быстро и позорно слился.

Порекомендую взять тот инструмент, который тебе удобнее. А монгу рекомендую изучить на досуге :).

Я уверен, что ты можешь беседовать со мной без моего участия :). Ты в любых словах видишь то, что ожидаешь.

Пока что я вижу это от тебя. Т.к. ты свои фантазии переносишь на меня.

Порекомендую взять тот инструмент, который тебе удобнее. А монгу рекомендую изучить на досуге :).

С чего ты взял, что я монго не знаю/не использую?
Завязывай фантазировать.

Неужели ты не ценишь время, которое тебе уделяет собеседник? Откуда столько желчи в тебе? Тебе нужно больше общаться с людьми в реале, чтобы не обрастать этой отвратительной манерой общения. Спасибо за беседу :).

Я думаю, ты парнишка не глупый, самостоятельный, и мои советы тебе не очень ценны :).

Cферический тролль в вакууме. Неаргументированные утверждения, манипулирование фактами, отвлеченные ответы на вопросы («мышление мол не такое»), а когда его таки сливают, обвинение оппонентов в бессердечности.

а чего ты ожидал? фанбои с синдромом утенка такие фанбои =/

и с вероятностью 99% тебе не нужен SQL.

fixed

aggregation framework и $elemMatch клево, да.

Будет посмотреть.

Свободный аналог Cache это GT.M http://en.wikipedia.org/wiki/GT.M

Улучнения в системе авторизации клиентов
Улучнения

Исправьте. В остальном новость отличная.

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