MongoDB uses a readers-writer [1] < http://docs.mongodb.org/manual/faq/concu... lock that allows concurrent reads access to a database but gives exclusive access to a single write operation. :))))))))))))))))))))))))))))))))))))))))))))
с другой стороны, за последствия принятия решения должен отвечать тот, кто его принял. камар такого хуёвого решения не принимал, следовательно, не должен отвечать за последствия.
ну и ебись со своими шардингами пока успешные люди разрабатывают приложения и зарабатывают деньги. а ты так и останешься никчемным задротом с повисшей монгой и шардингом
Сбрасывать список строк в единую кучу, чтоб потом докинуть не(обязательно)нужных индексов, чтоб потом при запросах джойнить и склеивать обратно — зато смотрите как у нас всё нормализовано.
ну рано или поздно, любой монгодебил начинает помнить наизусть исходники монги, когда из желания ОСТАВИТЬ МОНГУ ВО ЧТОБЫ ТО НИ СТАЛО, он медленно перепиливает её в аналог sqlite
и правда, зачем, например, декомпозить программу в эти объекты, функции, методы, чтобы потом их снова склеивать обратно — зато смотрите как у нас всё модульно
это была цитата из офф документации, у неё и спроси. Да, я знаю, что можно сделать = ANY(), например. Правда не знаю, можно ли построить индекс по всем элементам массива и затем искать, в реляционных БД я бы и правда сделал внешнюю таблицу и прочие один ко многим.
Ну как сказать. Мне кажется нормальным, когда ты сущность кладёшь в хранилище в том же виде, в котором она у тебя в программе. При этом разбивать сущность на кучу более мелких сущностей только ради того, чтоб подстроиться под БД мне иногда не хочется, особенно когда это нужно только потому что БД не позволяет иначе. Ну и как следствие — действительно можно держать большие сущности в отвязанности от остальных данных и шардить, например.
какая разница, в каком виде хранится сущность в бд? Интерфейс с бд в хорошем случае представляет собой: 1. исключительно views и редкие хранимки для выборок, 2. исключительно хранимки для изменения данных. Будет у тебя "select author, body, tags_array from posts_v where id = 123" для выборки, "add_post(author, body, tags_{array,string})" для добавления поста. Но профит от этого неиллюзорен: в простых случаях база данных не обязана работать с сущностями так, как работает с ними программа (чуешь дуальность?), а позволяет себе работать с сущностями так, как это выгоднее по производительности.
112 comments
recommend
bookmark
subscribe
Предвещаю отсутствие шардинга, а потом жалобы "почему оно плохо работает".
отпизди их ссаным тапком
Я написал на листке «а нехуй было выебываться» и запаковал его в конверт.
Через несколько месяцев вручу.
можно вручить сейчас и сказать когда распечатать
почему рельсовики дрочат на монгу?
Не все вообще-то.
Дрочат потому, что ЭСКУЭЛЬ ДЖОЙНЫ МИГРАЦИИ СХЕМЫ ААААА СПАСИТЕ НАС
я дрочу потому что можно сериализовать сложные документы, а потом по ним еще и искать.
Но очень многие. Ещё есть дрочащие на постгре, они кажутся более адекватными
СЛОЖНЫЕ ЗАПРОСЫ В RUBY ON RAILS потому что
О да, и поэтому тоже.
Собачую.
в аноосе поищи у себя, пёс.
нахуй сходи, уёбок
поуказывай в моём микробложике куда мне идти, пёс.
сейчас на BL нарвёшься
в чем проблема искать в таблицах?
Смотрите, он блэклистом угрожает.
ну там по всвяким tags: ['foo', 'bar'] не знаю, запилили ли уже, что уж говорить про вложенные документы и проч.
Вероятно необходимо чтобы при любом чихе лочилась вся база :)))
тип спокойнее, лал
и в чем проблема?
лол
чо за тип
пиздец кококой-то. Всячески уклоняйся от ответственности за работоспособность этого говна.
типичный пидораха
MongoDB uses a readers-writer [1] < http://docs.mongodb.org/manual/faq/concu... lock that allows concurrent reads access to a database but gives exclusive access to a single write operation. :))))))))))))))))))))))))))))))))))))))))))))
Exclusive VIP LUXURY 100% ACCESS
лел
не база а воркер-процесс, но да, это пиздец.
гав-гав
ппц говно какое-то, как вы это едите
ты так говоришь, как будто это что-то плохое.
с другой стороны, за последствия принятия решения должен отвечать тот, кто его принял. камар такого хуёвого решения не принимал, следовательно, не должен отвечать за последствия.
то есть по-твоему это нормально?
To search for a value in an array, each value must be checked. This can be done manually, if you know the size of the array. For example:
SELECT * FROM sal_emp WHERE pay_by_quarter[1] = 10000 OR
pay_by_quarter[2] = 10000 OR
pay_by_quarter[3] = 10000 OR
pay_by_quarter[4] = 10000;
ну или запили мне как бы ты хранил сущность поста со списком тегов и поиску по ним
посты, теги и таблица связей посты-теги. а потом бы выбирал посты для которых есть нужные связи
и ты считаешь это нормальным?
конечно это ненормально, лудше давай залочим базу и пусть весь мир подождет!
не базу а воркер (ну и они уже осознали свою тупость и потихоньку пилят нормальные локи).
а чо тут ненормального?
базы хуязы воркеры хуерки локи хуйлюки ХУЛИ МЕНЯ ВООБЩЕ ДОЛЖНЫ ЕБАТЬ ЭТИ ПРОБЛЕМЫ БЫДЛА?
деды писали на sql и нам завещали, самый умный дохуя?
слишком сложно для макаки просто
я говорю воркер, потому что можно достаточно просто сделать шардинг в случае нагрузки сервера, даже такой, где нормальные локи не помогут.
ну и ебись со своими шардингами пока успешные люди разрабатывают приложения и зарабатывают деньги. а ты так и останешься никчемным задротом с повисшей монгой и шардингом
С самого первого дня, няша.
У тебя ноуэскуэль головного мозга. Какой мудак будет так проектировать базу?
Я даже назову это нормализованным.
как проектировать базу? хранить список тегов списком строк?
да
mongodb is a webscale, бгг)))
Сбрасывать список строк в единую кучу, чтоб потом докинуть не(обязательно)нужных индексов, чтоб потом при запросах джойнить и склеивать обратно — зато смотрите как у нас всё нормализовано.
Кросс-таблица с индексами плоха?
Про ультрахайлоад ваш не знаю, как там будет, но думаю всяко лучше монги. :coolface:
> :coolface:
да съеби уже со своими шуточками смешными
нет, он просто тупой (слишком сложно для питониста)
гав-гав-гав
короч, типикал логика монгобляди: таблицы кококо связи кококо слишком сложно, лудше давайте насрем все в кучу, а дальше оно как-нибудь само
Это не смешные шуточки, а проверенный годами дизайн. А ты продолжай пить латте макиато со своими кофаундэрами в старбаксе)))
не сложно, просто не всегда это нужно, на мой взгляд
что ты пиздишь хуйню всякую? таблицы, джойны — всё очень нужно. просто не всегда.
для хелловордов конечно не нужно
> не всегда нужно
Ну с вашими кучами и sqlite справится наверное.
ненужно если у тебя 1 таблица
Я так личкрафты пишу.
типикал SQL-долбоёб, как только две таблицы — сразу МНОГО КО МНОГИМ, ДЖОЙНЫ ВСЕМ ДЖОЙНЫ
Че.
про тебя)))) http://blog.twelephone.com/post/40654080...
)))))))))))))))))))))))
куркума утверждает, что джойны не нужны только если у тебя одна таблица.
А как же джойниться с самим собой?
я в тебе не сомневался, няша :-*
*-:
ебать тебе бабахнуло
Вот еще про монгоцефалов)))) https://gist.github.com/raw/660696/09db9...
Не понимаю, кто ИТТ срется с кем и кто отстаивает какую точку зрения, но соснули все.
реддит-вей
Форевер-алон-вей.
хакир
Хэккер.
Давай я тебя заблеклищу, чтобы ты мне треды не портил.
заблэклисти ему дедик на хецнере)
ппц ты цензурщик, зачем ты ущемляешь свободу разрабов свободного по?
могу спалить как (не спалю)
> implying у разработчиков есть свобода
у меня есть свобода, я могу ругать путина в интернете
ппц ты
КОКОКО Я ТРАЧУ СВОБОДНОЕ ВРЕМЯ КОКОКО ВКЛАДЫВАЮ ДУШУ В ЛИЧЬКРАФТЫ КОКОКО СПАСАЮ МИР КОКОКО МУДАКИ
а сколько плагинов для личкрафтов УЖЕ написал ТЫ?
0
спасибо!
http://postgresql.ru.net/manual/function... зойчем сравнивать поэлементно?
Ты думаешь монгодебилы могут осилить документацию сложнее шести страничек?
ну рано или поздно, любой монгодебил начинает помнить наизусть исходники монги, когда из желания ОСТАВИТЬ МОНГУ ВО ЧТОБЫ ТО НИ СТАЛО, он медленно перепиливает её в аналог sqlite
> любой монгодебил начинает помнить наизусть исходники монги
Она на 70% из яваскрипта состоит?
не пали пилз
вроде бы на плюсцах на 76.7% https://github.com/mongodb/mongo
и правда, зачем, например, декомпозить программу в эти объекты, функции, методы, чтобы потом их снова склеивать обратно — зато смотрите как у нас всё модульно
зато без джойнов
!
Зато все просто и понятно, в одном месте, процессор все равно разберется!
лел
это была цитата из офф документации, у неё и спроси. Да, я знаю, что можно сделать = ANY(), например. Правда не знаю, можно ли построить индекс по всем элементам массива и затем искать, в реляционных БД я бы и правда сделал внешнюю таблицу и прочие один ко многим.
Посмотрите на этого долбоёба.
ты еще не успокоился?
Ну как сказать. Мне кажется нормальным, когда ты сущность кладёшь в хранилище в том же виде, в котором она у тебя в программе. При этом разбивать сущность на кучу более мелких сущностей только ради того, чтоб подстроиться под БД мне иногда не хочется, особенно когда это нужно только потому что БД не позволяет иначе. Ну и как следствие — действительно можно держать большие сущности в отвязанности от остальных данных и шардить, например.
> и шардить
> и шардить
> и шардить
давно думал, что мало декомпозиции, может каждую колонку в отдельную таблицу и один к одному? вот архитектура будет! охуеть просто.
web scale головного мозга, ужас просто.
Создаю шарды в /dev/null, оче быстро, тимлид хвалит.
было
> ко-ко-ко
Заставь дурака Богу молиться, он и лоб расшибёт.
какая разница, в каком виде хранится сущность в бд? Интерфейс с бд в хорошем случае представляет собой: 1. исключительно views и редкие хранимки для выборок, 2. исключительно хранимки для изменения данных. Будет у тебя "select author, body, tags_array from posts_v where id = 123" для выборки, "add_post(author, body, tags_{array,string})" для добавления поста. Но профит от этого неиллюзорен: в простых случаях база данных не обязана работать с сущностями так, как работает с ними программа (чуешь дуальность?), а позволяет себе работать с сущностями так, как это выгоднее по производительности.
это был ответ на /46, должно быть.