Guest
— Рано или поздно перед любым разработчиком встает проблема рассогласования импеданса между объектной и реляционной моделью. Звучит дико, конечно. Скажем проще. Рано или поздно каждому разработчику приходится хранить в базе данных что-то такое, что там хранить неудобно. Например, какой-то сущности надо приписывать какие-то дополнительные атрибуты, названия и типы данных. Или кто-то хочет отобразить на реляционные таблицы дерево наследования. Для этих задач есть известные проработанные и неудобные способы решения, которые к тому же легко могут привести к проблемам с производительностью. Альтернатива этому всему — хранение таких данных в виде JSON. Но реляционные СУБД JSON не любят. Дошло даже до того, что Mongo, киллер-фичей которой как раз является хранение данных в виде JSON, набрала на этом нешуточную популярность. Но, к счастью, эти времена потихоньку отступают. Во многом благодаря усилиям разработчиков PostgreSQL. Раньше все попытки положить JSON в базу данных встречали враждебную реакцию со стороны DBA, аналитиков и QA. Эту реакцию можно описать так: «У нас же тогда будет не база данных, а помойка!» Спикеры поговорят о связанных с этим проблемах, расскажут, как их можно решить не выходя из реляционной структуры, и продемонстрируют, что с этими решениями не так. Также вы узнаете, в каких случаях для решения этих проблем можно применить JSON и почему львиная доля опасений DBA, аналитиков и QA теперь неактуальна. А еще — как при использовании JSON не выстрелить себе в ногу, потому что нюансы есть. Ссылка на презентацию: #json #postgresql #hibernate #spring-data #jpa
