[mongodb] Странный выхлоп mongodb

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

Как связаны Монго и Гугл?

Ясно, что то как то экстремально не работает эксперимент если даже простой запрос не отрабатывает..

Версия стабильная? Не ночной билд какой-нибудь?

1.6.4 что в репах у центоса..

потому что кто-то не читает доки
http://127.0.0.1:28017/db/collect/?filter_uid="5b7ff430d6ff06378d2292d1a...

Обьясню. На вход нужен json. В твоем случае поле скастовалось в int, поскольку без кавычек

Странно, вроде пробовал так, спасибо

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

После redis mongo меня тоже расстраивает. У них целевое назначение конечно разное, но монго уж слишком не поворотлива для nosql db. Вообщем аккуратно работать с ней надо.

Мой код не падает. Да и зря вы меня жалеете - меня PostgreSQL устраивает на 100%. А ваше монго поддерживает транзакции только в пределах одной таблицы. Да здраствуют inconsistent data - вобщем то вся философия ваших новомодны nosql именно и является ничем иным как пропагандой наплевательского отношения к хранимым данным. За SQL стоит математическая теория а за вашими nosql-поделками что стоит? JSON?

Да здраствуют inconsistent dat

Да здравствует EAV и извращение при попытке запихнуть в реляционную модель то, что для неё не предназначено.

В постгре есть hstore. Так что делай вдоль, это ортогональные вещи.

против вашго sql и вашего постгре я ничего не имею и сам постоянно использую. но вы так говорите как а что стоит за вашими файлами? plain text?

В постгре есть hstore.

А разве hstore умеет что-то, кроме строк?

Никакого извращения в EAV не вижу. Это оно для тех извращение кто не смог осилить нормализацию и ушёл клепать дырявые поделки на новомодных недотехнологиях. Кроме того что может быть извращённее inconsistent data. Или вам уже совсем наплевать на вопросы security & reliability и всё в чём вы заинтересованы - что бы у вас код выглядел ООПистически красиво?

Никакого извращения в EAV не вижу.

Ну-ну. Реляционная структура в EAV далека от здравого смысла. Кроме того, массовые JOIN-ы дают значительно проседание производительности.

Кроме того что может быть извращённее inconsistent data.

С чего это в документ-ориентированных БД будет inconsistent data? Ну да, если мозг проеден EAV, то можно накрутить какие-нибудь сотни связей на пустом месте, и получить эту ситуацию, но зачем?

что бы у вас код выглядел ООПистически красиво?

Б-же мой, человек борется с ООП, но при этом приемлет кривейший EAV.

Да мне нравится EAV и я борюсь с тотальной опизацией. А что все должны боготворить ООП?

Прошу привести реализацию в mongo не поддерживающем транзакций на несколько таблиц реализацию такой схемы:

[code=sql] create table users ( id bigserial primary key, username varchar(64) not null unique, balance numeric(16,2) CHECK (balance > 0.00) ); create table transactions ( id bigserial primary key, source bigint references users (id), destination bigint references users (id), amount numeric(16,2) not null CHECK (amount > 0.00), created_on timestamp not null ); [/code]

Как объединить 2 таблицы в одну что бы можно было осуществить в транзакции `INSERT INTO transactions...` + `UPDATE users SET balance = ...`? Только не надо про ращётные периоды. Это удел советских бухгалтеров. Я что то не слышал что бы paypal или moneybookers прекращали работу что бы закончить ращётный период. Прикажите удалить users.balance и перещитывать транзакции за многие годы? Просвятите идиота с мозгом разъеденным кривым SQL как в вашей богоугодной монге такое сделать. Жду ответов.

Что ж за идиоты зделали этот TeX paragraphs по умолчанию!!!!!!

 create table users ( id bigserial primary key, username varchar(64) not null unique, balance numeric(16,2) CHECK (balance > 0.00) ); create table transactions ( id bigserial primary key, source bigint references users (id), destination bigint references users (id), amount numeric(16,2) not null CHECK (amount > 0.00), created_on timestamp not null ); 

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

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

Прикажите удалить users.balance и перещитывать транзакции за многие годы?

Не скажу за монго, но в couchdb результаты views, в общем-то, всегда кэшируются в готовом виде, и там этот подход является быстрым, простым и правильным.

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

Ну ладно, убедили - для бложика пойдёт ваш nosql.

http://www.mongodb.org/display/DOCS/Production Deployments