Бездны

[metaclass]

http://ru-programming.livejournal.com/1331711.html
"возможна ли вообще актуализация ежели таблицы сериализорваны и в виде джонсон строчек хранятся в одном единственном стобце физической таблицы."
Ничего не приходит в голову, кроме "ОБА УМРУТ!".

Comments

[bydlorus.livejournal.com]

СУППЛЯ ОН

[trueblacker.livejournal.com]

и стерилизация.
это когда приходят нигилисты и отрезают джонсон

[hahashi.livejournal.com]

schemaless дизайн
это типа "а давайте возьмем все самое у плохое у nosql и применим это в sql базе" ?

[vp.livejournal.com]

о, ОЧЕНЬ правильный комментарий и очень правильно сформулировано.

[sergiej.livejournal.com]

Ну разные бывают ситуёвины. Бывают и такие, при которых такой подход обоснован. Например если с данными этими надо работать исключительно в памяти и исключительно без связи с какими-либо другими объектами. В такой ситации решение - оптимально. Загружаешь конкретную "таблицу" и колбасишь её в памяти. Когда получилось (если получилось) справиться со всеми задачами и нужно записать - пишешь в базу. По сравнению с множественными чтениями-записями в базу это вин-вин.
Пару раз сталкивался с такой ситуацией и как раз такой подход двигал. Бейте меня ногами.

[plumqqz.livejournal.com]

Почему "бейте"? Экономия ввода-вывода; впрочем, обычно субд предоставлят свои средства для этого, но есть и такие, которые не.

[sergiej.livejournal.com]

Потому что это слишком многие считают некошерным. А я не стесняюсь внедрять в RDBMS данные в нужном мне формате, и на нормализацию базы мне честно говоря плевать если она мешает производительности или требует много работы.

[hahashi.livejournal.com]

у нас был другой usecase
стояла задача update-ить production без ухода в maintenance
т.е. мы как бы поднимаем еще один production environment указываем ту же базу и просто redirect-им часть запросов туда, типа тестим
если работает - переключаем полностью
ну а сериализаторы json-а поддерживают schema evolution стратегии
ад кароче =) хорошо что все пока так и осталось в зародыше

[sergiej.livejournal.com]

Ну это трешак другого класса, если бы требовалась такая динамика я бы продумал другую стратегию деплоймента. В одном проекте например динамические модули на жабе грузились прямо в базу и поднимались по мере переключения версий приходящих транзакций. В результате любой код можно было обкатывать без рестартов просто запустив тестовые пакеты с "новой" версией или с другой стороны, подменив скомпиленые уже жаба методы в базе, и откатить если чего не так можно было за доли секунды, так что за это время не успевало упасть критическое для бизнеса количество запросов. Дизайнил это не я, но я проникся и даже развил.

[hahashi.livejournal.com]

та у нас проблема в том что alter table может бежать сутки
поэтому решили что часть данных, для которых критично чтобы был referential integrity, оставить в таблицах как есть
остальное пусть хранятся как json в одной колонке
проблема в том что upвate-ы критичных данных с referential integrity происходят чаще чем хотелось бы =)

[sergiej.livejournal.com]

Если всё так динамично то здоровый подход, чего уж. Можно, конечно заняться релятивищиной и нормализацией, вынести это "остальное" в отдельную таблицу в виде атрибут+значение+ ссылка на объект. Но если по этим данным поиск не нужен, то это не даст никакой экономии а добавит проблем с огромными таблицами ("узкими" но "длинными" %)

[unbe.livejournal.com]

а зачем тогда нужна так называемая "база"? можно это же держать в так называемом "файле"

[sergiej.livejournal.com]

Ну другие то данные - в базе, женить базу с файловой системой можно конечно, но это значит искать проблемы. Кроме того при серьёзном количестве обращений файловая система ляжет мёртво, транзакционность обеспечить проблемно, залочивание надо решать тоже. А для традиционной базы это всё без проблем.