Даже не знаю что хуже — то что вы считаете что кэш не нужен никому, руководствуясь только своим опытом создания конструктора сайтиков, или то что вы дождались проблем, что бы проверить скорость запросов в проде.
Ну вообще хорошим вариантом было бы микросервис новостей выделить, и уже за его интерфейсом прятать возможные изменения схемы. Согласитесь, очень плохо, что 5 приложений лазят в одну базу.
2 еще понятно — (backend и www-frontend). Но не 5. От такой архитектуры никакие схемы не спасут.
И что будет в итоге в базе, если приложение 1 мигрирует схему до версии А, приложение 2 до версии Б, и они не совместимы друг с другом. Как вы будете решать конфликт?
Тут не в монге проблема, а в изначальной архитектуре. Вы рискуете получить мусорную базу, на одном из апдейтов.
Разговор был, что в sql базах схему надо описывать два раза и вместо того, чтобы решить эту проблему через скажем авто-генерацию вы предлагаете перейти на бд где нет схем.
Верно, про это. Я так и не понял, в чем плюсы двух уровней одинаковых описаний? Или слишком радикально выкидывать схемы? Все зависит опять таки от ситуации, для некоторых систем это действительно удобней. Я не говорю сейчас, что стал бы проектировать банковский процессинг или что-то подобное с mongo в бэкенде, это конечно не разумно. Но когда речь например про CMS, или про какую-то медийную платформу — это хорошее решение, для части данных.
Про транзакции: Есть множество примеров слабо связанных данных, для которых консистентность не сильно важна. Mongo и большинство noSQL решений реализуют 2 свойства из CAP теоремы: availability и parition tolerance. И они открыто говорят что консистентность — это как правило не к ним. Нужна консистетность: да, нужна Postgres, или Oracle DB. Это ни как не говорит о том, что отсутствие схем в Mongo — плохо.
Это все равно определение схемы на уровне приложения, формально.
Да есть куча миграторов: rails-овсие миграции для рубистов, south (который теперь в django orm), для java hibernate.
Но: если программист все равно не лазит в схему руками, и она отдана на откуп автогенераторам, зачем вообще нужен слой определения схемы на уровне БД? Зачем каждый раз 2 раза проверять валидность полей на каждом запросе?
Если скажете что для надежности, то если я сделал ошибку в описании схемы на уровне прилы(не поставил проверку уникальности, неправильное ограничение на поле), она автоматом замапится в БД). Эти ошибки должны ловиться авто-тестами, а не двойными идентичными проверками.
Который раз уже люди ноют — без схем плохо. Правильный путь — схемы нужны, но на уровне приложения. Философия в том, что не нужно определять схему два раза, достаточно это сделать в приложении.
В случае с sql-базами, схема определятся два раза: на уровне приложения, и на уровне базы.
2 еще понятно — (backend и www-frontend). Но не 5. От такой архитектуры никакие схемы не спасут.
И что будет в итоге в базе, если приложение 1 мигрирует схему до версии А, приложение 2 до версии Б, и они не совместимы друг с другом. Как вы будете решать конфликт?
Тут не в монге проблема, а в изначальной архитектуре. Вы рискуете получить мусорную базу, на одном из апдейтов.
Верно, про это. Я так и не понял, в чем плюсы двух уровней одинаковых описаний? Или слишком радикально выкидывать схемы? Все зависит опять таки от ситуации, для некоторых систем это действительно удобней. Я не говорю сейчас, что стал бы проектировать банковский процессинг или что-то подобное с mongo в бэкенде, это конечно не разумно. Но когда речь например про CMS, или про какую-то медийную платформу — это хорошее решение, для части данных.
Про транзакции: Есть множество примеров слабо связанных данных, для которых консистентность не сильно важна. Mongo и большинство noSQL решений реализуют 2 свойства из CAP теоремы: availability и parition tolerance. И они открыто говорят что консистентность — это как правило не к ним. Нужна консистетность: да, нужна Postgres, или Oracle DB. Это ни как не говорит о том, что отсутствие схем в Mongo — плохо.
А проблемы с транзакциями, из-за неправильно выбора СУБД и инертности мышления,. Люди пытаются применить подходы из SQL в noSQL.
Да есть куча миграторов: rails-овсие миграции для рубистов, south (который теперь в django orm), для java hibernate.
Но: если программист все равно не лазит в схему руками, и она отдана на откуп автогенераторам, зачем вообще нужен слой определения схемы на уровне БД? Зачем каждый раз 2 раза проверять валидность полей на каждом запросе?
Если скажете что для надежности, то если я сделал ошибку в описании схемы на уровне прилы(не поставил проверку уникальности, неправильное ограничение на поле), она автоматом замапится в БД). Эти ошибки должны ловиться авто-тестами, а не двойными идентичными проверками.
В случае с sql-базами, схема определятся два раза: на уровне приложения, и на уровне базы.
Спасибо, интересный вариант реанимации.
Челябинск,2000 км от Москвы)