Согласен, что реальный, сам такое «творил», все мы когда учились… но это не повод теперь отказывать себе в удовольствии поработать с удобным и быстрым инструментом.
ну говорил жу уже есть два варианта.
1) делать так как пишут во всех примерах для nosql
2) так же как вы делаете в релационной БД, но собирать все нужно «вручную» (у меня это делает модель).
post._id
post.title
tag._id
tag.title
post_tag._id
post_tag.post_id
post_tag.tag_id
«в «третьей» коллекции запись есть, а id таких нет» — это проблема в голове. Одинаково плохо можно использовать и nosql и sql, поэтому этот пример ничего не доказывает.
«SQL решение, что само за всем следит» — соглашусь, это иногда может быть удобно, но за это удобство вы заплатите производительностью и сложностями в проектировании и модифицировании структуры данных.
Да «банковские» задачи без транзакций не решаются. А их в монге нет.
Ну и я не банк и настолько критичных данных у меня нет, а есть ли они у 80% разработчиков?
В вашем примере про парты их тоже нет.
А все остальное сделать можно, работает очень быстро, разработка гораздо проще.
Модель у меня следит за целостностью.
Для решения проблемы многие ко многим использовал бы map/reduce ну или как вариант теже три коллекции как и в реляционной модели.
Имеете ввиду внешние ключи? Или что-то иное?
Я 2 года пишу проект с использованием монги, где не менее полусотни моделей, связанных между собой.
Имеется несколько миллионов зарегистрированных юзеров (т.е. не студенческий проект) и не столкнулся с особыми проблемами.
Есть только одна — транзакции.
Автор статьи очень правильно сказал:
MongoDB не требует описания схем таблиц благодаря чему вы можете с легкостью сохранять объекты, и таким образом быстрее приспосабливаться к изменениям в требованиях...
Glue — удобный инструмент генерации спрайтов (CSS и PNG) для командной строки. Есть куча настроек, поддерживает LESS, написан на питончике, регулярно обновляется.
«единственно реальный на сегодня вариант по созданию подобной системы вижу некую информ.базу, которая будет цеплять по апи кучу сервисов для работы с информацией»
Согласен и обеими руками «за», однако остается вопрос — кто этим будет пользоваться? 10 технарей? Кто аудитория?
Да и за хлебом сходить:
— узнать какой хлеб отсутствует — знаем какой покупать (план),
— зная, что покупать берем нужное кол-во денег (ресурсы),
— думаем как лучше дойти до магазина (стратегия действий :)),
— покупаем (реализация)
Хорошая статья, кратко, по делу, да еще и линк на репо. Спасибо, как раз искал что-то такое.
jsman.ru/mongo-book/Glava-4-Modelirovanie-dannyh.html
1) делать так как пишут во всех примерах для nosql
2) так же как вы делаете в релационной БД, но собирать все нужно «вручную» (у меня это делает модель).
post._id
post.title
tag._id
tag.title
post_tag._id
post_tag.post_id
post_tag.tag_id
«SQL решение, что само за всем следит» — соглашусь, это иногда может быть удобно, но за это удобство вы заплатите производительностью и сложностями в проектировании и модифицировании структуры данных.
Да «банковские» задачи без транзакций не решаются. А их в монге нет.
Ну и я не банк и настолько критичных данных у меня нет, а есть ли они у 80% разработчиков?
В вашем примере про парты их тоже нет.
А все остальное сделать можно, работает очень быстро, разработка гораздо проще.
Для решения проблемы многие ко многим использовал бы map/reduce ну или как вариант теже три коллекции как и в реляционной модели.
Я делаю точно так же как и в реляционной модели если я знаю что у меня не должно быть ограничений по объему данных.
Я 2 года пишу проект с использованием монги, где не менее полусотни моделей, связанных между собой.
Имеется несколько миллионов зарегистрированных юзеров (т.е. не студенческий проект) и не столкнулся с особыми проблемами.
Есть только одна — транзакции.
Автор статьи очень правильно сказал:
Это я чувствую каждый день на себе.
Согласен и обеими руками «за», однако остается вопрос — кто этим будет пользоваться? 10 технарей? Кто аудитория?
— узнать какой хлеб отсутствует — знаем какой покупать (план),
— зная, что покупать берем нужное кол-во денег (ресурсы),
— думаем как лучше дойти до магазина (стратегия действий :)),
— покупаем (реализация)