Я не уверен насчет «рекомендованных», но стоит выделить преимущества и недостатки.
Преимущество вашего решения заключается в том, что оно позволяет вам моделировать большую часть вашего домена в базе данных и применять референтные ссылки. целостность - таблица user_movie_like
может иметь внешний ключ к таблице movie
, и вы можете избежать ошибок типа «мы удалили mov ie, но забыли удалить все лайки». Я полагаю, что для определенных действий кэширование имени mov ie в MySQL позволит избежать обращения к MongoDB для получения имени и, следовательно, ускорит работу вашего приложения.
Используя MongoDB для неструктурированных данных, вы может иметь дело с незнанием схемы заранее.
Недостатки в том, что вы используете два отдельных хранилища данных для своего приложения - вы можете, например, хранить неструктурированные данные mov ie в JSON объекты в MySQL и избегают двух наборов запросов.
Другим недостатком является то, что кэшируя имя mov ie в MySQL, вы вводите возможности для ошибок - если вы обновляете имя mov ie в MongoDB, но не в MySQL, ваше приложение может вести себя странно.
Еще один недостаток - отсутствие встроенного механизма, гарантирующего целостность ссылок в двух хранилищах данных - вы можете удалить mov ie в MongoDB, но не в MySQL.