RC
я бы предпочел контроллировать это заранее накатив миграцию и чтобы аппка не писала кривые данные, а падала
Size: a a a
2020 February 25
RC
Ну, она by design даёт одну версию моделей
ну можно же кодом это регулировать
AO
Это не про денормализацию
RC
а, я понял о чем ты
RC
мне кажется проще делать промежуточные релизы, когда переезжаешь с одного поля на другое
RC
хотя бы уверен что данные не протерял
AO
мне кажется проще делать промежуточные релизы, когда переезжаешь с одного поля на другое
Это проще потому что выбора другого нет)
AO
А вот с монгами он есть)
RC
надо поиграться
AO
Попробуй облачные типа Firestore
AO
Это удобно: ничего ставить не нужно
E
я за свою недолгую (всего шесть лет) карьеру (хех) никогда не использовал nosql как основную бд, всегда постгрес и погнали, расскажите хоть в каких ситуациях мне монгу ту же использовать?)
не знаю на счет монги, но бывает необходимость использовать что-то типа яндексового кликхауса. это специфичная вещь, которую классическая реляционная бд не заменит.
RC
ну кликхаус понятно, уже года три его юзаю
RC
я имею в виду замену основной бд
E
я имею в виду замену основной бд
Я про эту статью вспомнил в контексте обсуждения
https://habr.com/ru/post/231213/
https://habr.com/ru/post/231213/
E
но она 6-летней давности, может сейчас всё уже изменилось. я то сам с базами практически не работаю :)
AO
я имею в виду замену основной бд
Если тебя устраивает наличие миграций и привязанность миграций к релизу новой версии и связанный с этим оффлайн, то PostgreSQL нормальный выбор...
RC
Если тебя устраивает наличие миграций и привязанность миграций к релизу новой версии и связанный с этим оффлайн, то PostgreSQL нормальный выбор...
офлайн?
RC
я ниразу не делал миграций которые ломают обратную совместимость)
AO
офлайн?
Если большие таблицы - миграции могут идти некоторое время