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