Комментарии 3
Остался только вопрос «зачем»? Вам не кажется, что хранение настолько связанных «по домену» сущьностей в разных БД не кошерно?
Правильно. Поэтому, нужно переходить на лучшее
А если серьезно, то благодаря связанности «по домену» полностью перешли на MongoDB. Разработчики в восторге. Ну а практика покажет эффективность.
Есть, правда, некоторые «затыки» в производительности doctrine-mongodb-odm, но судя по всему, если бы мы привели в «нормальную форму» модели ORM (если это применимо к ним :}), то наблюдался бы эффект похуже.
А если серьезно, то благодаря связанности «по домену» полностью перешли на MongoDB. Разработчики в восторге. Ну а практика покажет эффективность.
Есть, правда, некоторые «затыки» в производительности doctrine-mongodb-odm, но судя по всему, если бы мы привели в «нормальную форму» модели ORM (если это применимо к ним :}), то наблюдался бы эффект похуже.
второе использования для такого варианта:
вместо MongoDB, можно использовать ElasticSearch. Данные хранятся в MySQL, и специальные расширенные данные для постройки фасетов, поиска, получения записей храняться в ElasticSearch.
Т.к ES, в таком случае не primary storage, то в нем, данные просто дублируются и используются только когда это необходимо: Поиск, Фасеты, Статистика.
В таком случае, такой подход очень даже ничего.
вместо MongoDB, можно использовать ElasticSearch. Данные хранятся в MySQL, и специальные расширенные данные для постройки фасетов, поиска, получения записей храняться в ElasticSearch.
Т.к ES, в таком случае не primary storage, то в нем, данные просто дублируются и используются только когда это необходимо: Поиск, Фасеты, Статистика.
В таком случае, такой подход очень даже ничего.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Связываем Doctrine Entity и Doctrine Document на форме в Sonata Admin Bundle