Viji
@Viji
DevOps Engineer

Является ли приемлимой практикой использование JSON обьектов в столбцах таблицы базы данных PostgreSQL?

Есть таблица в базе PostgreSQL, где хранится сложный JSON объект, который достается Select след образом:

SELECT customer.id AS cid,
           COALESCE(cd.document->>'Line', ad.document->>'Line') as line,
           COALESCE(cd.document->>'Town', ad.document->>'Town') as town,
           DATE(cidc.check_document->'IDCheck'->'Profile'->>'TheNextReviewDate') as _nextreview,
		   (cidc.message_document->'ProspectMessage'->'RiskPro'->>'RiskLev') as risk_level
    FROM public.customers;

Как видно из примера некоторые строки обращаются к значениям заключенным внутри JSON объекта. Типа DATE(cidc.check_document->'IDCheck'->'Profile'->>'TheNextReviewDate') as _nextreview. Является ли это нормальной практикой и как это лучше оптимизировать?
  • Вопрос задан
  • 123 просмотра
Решения вопроса 2
ma4akk
@ma4akk
Использование JSON объектов в столбцах таблицы базы данных PostgreSQL является приемлимой практикой и позволяет хранить сложные структуры данных в едином формате. Это упрощает их обработку и извлечение нужных данных в запросах. Однако, также следует учитывать, что хранение больших объемов данных в формате JSON может замедлить работу базы данных и увеличить нагрузку на сервер. Поэтому рекомендуется проводить оптимизацию запросов и использовать индексы для ускорения работы с JSON данными.
Ответ написан
@Akina
Сетевой и системный админ, SQL-программист.
Если говорить об общем подходе - JSON в БД должен использоваться только и исключительно в случае, когда вся работа с JSON ограничивается простейшим "записать в БД" - "извлечь из БД". При этом модификация в момент записи/извлечения можно не учитывать.

Если же JSON используется более нагруженно (поиск, сравнение, частичная модификация и пр.), то в большинстве случаев от его использования следует отказываться в пользу нормализованных plain-структур. При правильном индексировании они выиграют у JSON по потреблению ресурсов сервера. Хотя, конечно, в каждом отдельном случае нужно смотреть конкретные условия - тип использования, возможности оптимизации этого процесса в конкретной (версии) СУБД и пр. Да и то, JSON тут реально может конкурировать разве что с EAV.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы