Локализация.
«NoSQL никаких преимуществ тут не даёт.»
С NoSQL это делать гораздо удобнее.
Связи.
«несколько решений, все они приемлемы в зависимости от требований задачи»
Проще связь хранить в самом объекте — в MongoDB это делать удобно.
Объекты с разным набором полей в одной таблице
«Ради бога! Не путайте «нам нужно вывести список на страничку» с «нам нужно всё хранить в одной таблице» — это РАЗНЫЕ вещи»
Я ничего не путаю. Я НЕ хочу их хранить в разных таблицах. Мне удобнее хранить их в одной. И проще это делать в MongoDB.
Сложные объекты
«Тот же JSON в PostgreSQL вполне «поискуем»»
Мне хватает поискуемости в MongoDB.
Итого, вы предлагаете набор разных частных решений, для того, что можно решить (и уже решено) нормально одним инструментом.
Конечно учитываются. Еще раз — выбор пал на монгу из за того, что в свете изложенных выше требований с ней легче работать.
Не быстрее, не правильнее, а легче.
«вот на столько стало МЕНЬШЕ(?) кода/времени/памяти и вот так увеличилась гибкость по расширению системы»
По большому счету не важно, медленнее работает монга или быстрее чем та же MySQL, в конце концов узкие участки всегда можно будет переложить на MySQL. Важнее именно удобство разработки, об этом и статья.
Сложно комментировать, когда за тебя уже все решили и до кучи еще и диагноз поставили, но я всетаки попробую.
Статья называется «Почему мы выбрали MongoDB».
Выбор основан не столько на требованиях, сколько на удобстве разработки в соответствии с требованиями.
Эту же задачу можно решить вообще без использования SQL/NoSQL решений, но зачем? Вопрос в удобстве, нам удобнее так и в статье описывается почему.
«Желание «попробовать что-то новое» было выше, чем «сделать эффективно»?»
Нет — мне кажется в статье видно, что еще до знакомства с MongoDB мы перешли на сходный с монгой принцип хранения данных. Монга была не чем то новым, а скорее ответом на наши потребности.
С разными приходилось, сейчас вот приходится работать firebird. Но наверно 99% времени я работал с MySQL.
Если сравнивать PostgreSQL и MongoDB, то для меня проще работать с монгой — это наверно основная причина. Мне не нужно думать — какие данные пойдут в json, а какие в основные поля таблицы, не придется думать о миграции полей из json в поля таблицы и обратно. Не придется вообще работать с таблицами, мне нравится, что у монги есть полноценный яваскрипт в консоли, что мне не придется думать об sql injection, если я отдам какие то модули на аутсорс. Как то так.
Привет, Слай.
А сделано все так же как и в случае хранилища. Ничего кардинально не поменялось. Объекты выглядят практически так же как и в примере с $company. Только теперь не нужно еще вручную делать индексы, все из коробки.
С MySQL я бы и сейчас наверно не сделал бы быстро, слишком много накладных расходов на разработку.
И если бы MongoDB была сама по себе, в вакууме — пришлось бы создавать инструменты для работы с ней (админка, orm) — это тоже сильно затормозило бы.
Я тоже, когда услышал про поддержку json — порадовался за них, мне кажется это хороший вектор для развития. В нашем случае это одна из вещей, которой сильно не хватало.
«хотите использовать кеширующий индекс — используйте тогда сфинкс»
Последняя фраза относится именно к нашей ситуации. Я не представляю как бы мы мигрировали с монги обратно на mysql, но вполне допускаю что какие то функции mysql нам понадобятся.
Сфинкс уже используем и в принципе я буду до последнего стараться работать именно с ним.
Можно еще такую аналогию привести — чем больше частиц в каком то объеме пространства вселенной, тем там медленнее течет время. Для черных дыр оно вообще почти останавливается.
Я с SQL работаю больше 11 лет. И прямые запросы и orm и как угодно.
Так я вроде ничего и не доказываю.
Вы не правы. У нас почти сразу разделилась контентная часть и дизайн. Для дизайна удобно использовать gettext. Для контентной части нет.
«NoSQL никаких преимуществ тут не даёт.»
С NoSQL это делать гораздо удобнее.
Связи.
«несколько решений, все они приемлемы в зависимости от требований задачи»
Проще связь хранить в самом объекте — в MongoDB это делать удобно.
Объекты с разным набором полей в одной таблице
«Ради бога! Не путайте «нам нужно вывести список на страничку» с «нам нужно всё хранить в одной таблице» — это РАЗНЫЕ вещи»
Я ничего не путаю. Я НЕ хочу их хранить в разных таблицах. Мне удобнее хранить их в одной. И проще это делать в MongoDB.
Сложные объекты
«Тот же JSON в PostgreSQL вполне «поискуем»»
Мне хватает поискуемости в MongoDB.
Итого, вы предлагаете набор разных частных решений, для того, что можно решить (и уже решено) нормально одним инструментом.
Конечно учитываются. Еще раз — выбор пал на монгу из за того, что в свете изложенных выше требований с ней легче работать.
Не быстрее, не правильнее, а легче.
«вот на столько стало МЕНЬШЕ(?) кода/времени/памяти и вот так увеличилась гибкость по расширению системы»
По большому счету не важно, медленнее работает монга или быстрее чем та же MySQL, в конце концов узкие участки всегда можно будет переложить на MySQL. Важнее именно удобство разработки, об этом и статья.
«ваш выбор сугубо индивидуальный»
Именно так.
Статья называется «Почему мы выбрали MongoDB».
Выбор основан не столько на требованиях, сколько на удобстве разработки в соответствии с требованиями.
Эту же задачу можно решить вообще без использования SQL/NoSQL решений, но зачем? Вопрос в удобстве, нам удобнее так и в статье описывается почему.
Нет — мне кажется в статье видно, что еще до знакомства с MongoDB мы перешли на сходный с монгой принцип хранения данных. Монга была не чем то новым, а скорее ответом на наши потребности.
Если сравнивать PostgreSQL и MongoDB, то для меня проще работать с монгой — это наверно основная причина. Мне не нужно думать — какие данные пойдут в json, а какие в основные поля таблицы, не придется думать о миграции полей из json в поля таблицы и обратно. Не придется вообще работать с таблицами, мне нравится, что у монги есть полноценный яваскрипт в консоли, что мне не придется думать об sql injection, если я отдам какие то модули на аутсорс. Как то так.
Фронтенд: backbone-forms — большой плюс — поддержка вложенных форм.
Выглядит все это как то так:
А сделано все так же как и в случае хранилища. Ничего кардинально не поменялось. Объекты выглядят практически так же как и в примере с $company. Только теперь не нужно еще вручную делать индексы, все из коробки.
И если бы MongoDB была сама по себе, в вакууме — пришлось бы создавать инструменты для работы с ней (админка, orm) — это тоже сильно затормозило бы.
Последняя фраза относится именно к нашей ситуации. Я не представляю как бы мы мигрировали с монги обратно на mysql, но вполне допускаю что какие то функции mysql нам понадобятся.
Сфинкс уже используем и в принципе я буду до последнего стараться работать именно с ним.
Плюс люди из первого раунда своими деньгами и рисками отсеивают плохие проекты, а хорошие преподносят на блюдечке для инвесторов второго раунда.
А если я не хочу продавать свою долю?