Replies (24)

  • @hizel, При всей моей нелюбви к монге и при том, что в статье есть по делу замечания, вот с этого проиграл:
    Another core problem we’ve faced is one of the fundamental features of MongoDB (or any other schemaless storage engine): the lack of a schema
  • @tosh, забивать саморезы молотком, потом жаловатся какой негодный молоток и шуруповерт рулит
  • @hizel, Но таки жалобы на глобал локи и дебильные репорты (== их отсутствие), вкупе с отсутствием тюнинга — они к изначальной идеи базы, а не к её применению.
  • @tosh, Схемалесс гомно для почти всего, кроме придуманных под это юзкейсов
  • @SannySanoff, Схемалесс решает проблему EAV, например, которая придумана задолго до схемалесс. И тут, увы, ничего не поделать. Проблема монги в самой монге, а не в схемалесс/носкл
  • @tosh, Проблема у нее с любым проектом, переросшим определенный, очень маленький, размер. Для остальных, конечно, ОК.
  • @SannySanoff, Вроде, это не опровергалось в предыдущем сообщении
  • @tosh, Посмотрел что такое EAV, не понял что в монге такого что помогает решать. Индексы на конкретные атрибуты — часть схемы что в монге что в ralational, без индексов фуллскан исключаем ибо абсурдно, а целиком остальные атрибуты ходят что там что сям, разве что сериализовать их самому или в детях держать... Физически рядом расположенные дети уже много лет в relational есть. А чем же профит?
  • @SannySanoff, Какие индексы на конкретные атрибуты, что несёшь? Просто отсутствие схемы подразумевает, что можешь лепить какие угодно поля, а потом по ним селектить невозбранно. В реляционке под это дело либо несколько m2m делать, либо брать полное множество и подо все элементы по полю делать.
  • @tosh, Какие индексы?
    по ним селектить невозбранно

    Иди, пиши свои лабы дальше.
  • @SannySanoff, охохо, профессиональный погромист порвался
  • @tosh, поля ты лепить будешь, но индексы на них все равно вешать придется, когда ты соберешься по ним фильтровать
  • @netoneko, С ними никаких проблем нет. Изначальная проблема eav в другом, что я и пытался донести до автора комментариев выше.
  • @tosh, Не нужно мне это доносить, это у меня уже есть. Я даже уже сказал, что обычно доп. атрибуты всё равно потом по-любому ходят слабо структурированной пачкой, из которой потом их вытаскивать по-одному руками, и это делается на уровне application, а отнюдь не storage (исключая единичные патологические случаи, которые конечно же можно всегда найти), поэтому совершенно пофигу как они в storage хранятся, одним блобом или номинально вперемешку с индексируемыми колонками.
  • @SannySanoff, блобомОоо да, обожаю это хранение в неразгребаемой куче. Это конечно лучше, чем человеческими полями.
  • @tosh, да какая фиг разница. Таких таблиц с мусоркой на весь проект бывает 1-2 штуки, а чаще всего ноль, и ДАЖЕ ЕСЛИ действительно mongodb дает преимущество ИМЕННО В ЭТОМ случае, все его недостатки успешно перевешивают это достоинство 8)
  • @SannySanoff, Вроде, я в итоге и не приходил, к тому что надо использовать именно монгу. Мы про схемалесс разговаривали. А то, что в проекте таких таблиц не бывает, напоминает мне классическую байку про "такие данные не могут прийти". Просто тебе повезло и ты не сталкивался
  • @tosh, Ок, я согласен, что позитивное свойство "schemaless" это удобство хранения мусорок, но отрицательные свойства того же схемалесс, втч перечисленные в материале, сводят на нет всё удобство. Я еще скажу, в текстовых файлах удобно хранить мусорки, но остальное тоже делать неудобно, как и в монге. Если проект сколько-тол большой. Если маленький, то всем пофиг, конечно.
  • @SannySanoff, Много разных проектов с базами за плечами, видимо?)
  • @tosh, Та дофига уже.
  • @SannySanoff, И только щаз про eav-кейс узнал? Странно.
  • @tosh, Вот ведь люди. Ты не допускаешь, что эту проблему я решал не в одном проекте, просто не зная, что у нее есть, оказывается, такое название? И решал ее и блобом, и в монге.
  • @SannySanoff, Ты не переживай, я уже понял, что мастерство на уровне )
  • @tosh, Спасибо, погладил!!!! 8-))))