http://ru-programming.livejournal.com/1331711.html "возможна ли вообще актуализация ежели таблицы сериализорваны и в виде джонсон строчек хранятся в одном единственном стобце физической таблицы." Ничего не приходит в голову, кроме "ОБА УМРУТ!".
у нас был другой usecase стояла задача update-ить production без ухода в maintenance т.е. мы как бы поднимаем еще один production environment указываем ту же базу и просто redirect-им часть запросов туда, типа тестим если работает - переключаем полностью ну а сериализаторы json-а поддерживают schema evolution стратегии ад кароче =) хорошо что все пока так и осталось в зародыше
Ну это трешак другого класса, если бы требовалась такая динамика я бы продумал другую стратегию деплоймента. В одном проекте например динамические модули на жабе грузились прямо в базу и поднимались по мере переключения версий приходящих транзакций. В результате любой код можно было обкатывать без рестартов просто запустив тестовые пакеты с "новой" версией или с другой стороны, подменив скомпиленые уже жаба методы в базе, и откатить если чего не так можно было за доли секунды, так что за это время не успевало упасть критическое для бизнеса количество запросов. Дизайнил это не я, но я проникся и даже развил.
та у нас проблема в том что alter table может бежать сутки поэтому решили что часть данных, для которых критично чтобы был referential integrity, оставить в таблицах как есть остальное пусть хранятся как json в одной колонке проблема в том что upвate-ы критичных данных с referential integrity происходят чаще чем хотелось бы =)
Если всё так динамично то здоровый подход, чего уж. Можно, конечно заняться релятивищиной и нормализацией, вынести это "остальное" в отдельную таблицу в виде атрибут+значение+ ссылка на объект. Но если по этим данным поиск не нужен, то это не даст никакой экономии а добавит проблем с огромными таблицами ("узкими" но "длинными" %)
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
стояла задача update-ить production без ухода в maintenance
т.е. мы как бы поднимаем еще один production environment указываем ту же базу и просто redirect-им часть запросов туда, типа тестим
если работает - переключаем полностью
ну а сериализаторы json-а поддерживают schema evolution стратегии
ад кароче =) хорошо что все пока так и осталось в зародыше
no subject
no subject
поэтому решили что часть данных, для которых критично чтобы был referential integrity, оставить в таблицах как есть
остальное пусть хранятся как json в одной колонке
проблема в том что upвate-ы критичных данных с referential integrity происходят чаще чем хотелось бы =)
no subject