Какие нюансы использования Json записи в одну строку БД в сравнении с записью данных по заранее созданной структуре колонок?

Question

[blabs]

Проект наисан на PHP7, PostgreSQL. Проектируем архитектуру БД, рассматриваем вариант добавления одной колонки с Json массивом или распределением данных по каждой колонке в отдельности. В первом случае получается более гибкая модель, которую можно легко масштабировать. Во втором случае четкая структура.

Вопросы:
1. Поделитесь опытом использования первой и второй методологии. По нашему опыту были случае, когда в Json массиве были случайно указаны буквы на кириллице, мы несколько часов не могли найти причину ошибок.
2. Если использовать Json массив одной строки с дальнейшим интерфейсом чтения этой строки, на сколько это отразится на нагрузке сервера при хайлоад запросах?

Пример первого варианта

Parametrs - список всех параметров
- Id
- Name (Название параметра)
- Type_field (Тип строки: Число, True/False, Текст)
- Date_created

Type – типы доступных локаций
- Id
- Name (Название)
- Parametrs (Заведение параметров, по которому создаются дополнительные настройки. К примеру: {give_coupons_enable}, {fortune_chance}, {link_on_the_button}, {cost_coins})
- Status (Enable/Disable) (Статус Активен или нет)
- Date_created (Дата создания)

Location – список заведенных наград с привязкой к кампании
- Id
- Id_type (Идентификатор типа)
- type_parametrs_value (Настройка параметров)
- Name (Название)
- Description (описание)
- Picture (Картинка)
- Date_created (Дата создания)

Comments

[Rsa97]

Простите, что можно делать с моделью???

[Boris Köln]

По Фрейду

Answer 1

[Rsa97]

JSON есть смысл использовать исключительно для хранения данных. Если по данным нужен поиск, сортировка, слияние таблиц - только классическая многоколоночная/многотабличная структура.

Comments

[blabs]

Json нужен для чтения с последующей логикой обработки. Т.е. сортировать данные, искать по данным внутри мы не будем. Прочитали всю строку, обработали данные и после воспроизвели логику на базе полученных данных. Результат записали в другую таблицу.

На сколько в этом случае подходит такой формат?

[Rsa97]

blabs, Если в JSON только хранение, то для БД это просто текстовое поле. Там может быть хоть JSON, хоть XML, хоть сериализованные данные из PHP, хоть ваш собственный формат, базе всё равно. Она получила строку, вернула строку.
А по времени такой способ быстрее, чем слияние таблиц.

Answer 2

[Александр Шелеметьев]

Rsa97 не совсем прав. Начиная с версии 9.6 PostgreSQL прекрасно индексирует содержимое JSONB.
В большинстве случаев поиск для JSONB будет быстрее, чем в классической реляционной схеме, т.к. экономятся ресурсы на выборку из связанных таблиц. И вообще, по определению, выборка из денормализованных данных при наличии необходимых индексов производится быстрее, чем из реляционных.
Использовать JSONB есть смысл тогда, когда вы можете пожертвовать ссылочной целостностью данных внутри JSON.
Например, у вас в JSON хранится информация о наградах в кампании. Затем информация о кампании удаляется. Ссылки в JSON остаются. Их надо будет удалять/изменять отдельно.
В реляционной же модели существуют штатные механизмы удаления/изменения зависимых записей связанной таблицы.
Также выбирайте JSONB, если записи у вас в основном только добавляются, а изменение или удаление отдельных записей бывает редко либо в содержимом этих записей нет ссылок на другие сущности.

Comments

[entermix]

Просто дополню, что в MySQL 5.7+ тоже работает с JSON

https://dev.mysql.com/doc/refman/5.7/en/json.html