JSON в базе данных это норма для реляционных баз данных?

Question

[Евгений Усачев]

Я понимаю, что тут не может быть однозначного ответа, поэтому я хочу услышать скорее не ответ, а его объяснение. В не реляционных базах данных это считается хорошей практикой. Но в реляционных всё странно — сам принцип реляционных баз данных говорит, что для одного поля строго одно значение, однако в Postgresql поддерживается формат JSON, это объективно более производительное решение во многих случаях и некоторые медийные люди заявляют о необходимости таких решений.
Теперь несколько маленьких вопросов:
Можно ли использовать JSON формат, если нагрузка слишком большая или надо переходить на другую базу данных?
Насколько плохой практикой является использование JSON в реляционных базах данных (это строго запрещено, иногда разрешается или это хороший тон)?

Comments

[Kentavr16]

А в чем проблема если json может быть приведен к строке? Или специфика вопроса другая и я чего не понял?

[Евгений Усачев]

Kentavr16, специфика вопроса в этичности этого решения. Есть строгие стандарты написания "чистого кода" и спорные вопросы. Например, все названия классов начинаются с большой буквы. Код, скорее всего (зависит от языка), скомпилируется. Но это будет нарушением правил "чистого кода". Так что вопрос можно было сформулировать так: "Насколько меня будут осуждать коллеги за то, что я использовал JSON в реляционной базе данных?".

[ThunderCat]

Евгений Усачев,

"Насколько меня будут осуждать коллеги за то, что я использовал JSON в реляционной базе данных?".

Если он используется в контексте "текстовое поле, используемое больше как справочное или какие-то мелкие настройки" то и ок. Если это попытка заменить стандартные механизмы реляционности - будут скорее всего больно бить.

Answer 1

[Андрей]

Если нет частых апдейтов поля с json - то вполне можно его использовать.
Кроме полей, которые под внешние ключи либо выборки.
Хорошо хранить данные, которые не имеют четкой структуры, либо эта структура может часто изменяться.
Например, результаты каких-нибудь сборов данных вполне можно хранить в jsonb-поле.

Answer 2

[Saboteur]

В любом базе можно хранить. Вопрос в том, что проще - брать json из базы и парсить его внутри на нужные значения, или хранить все значения в отдельных полях в базе.
Это больше вопрос конкретного проекта и конкретного использования.
А так - со стороны базы - никаких проблем в этом нет. Можно хранить как text или блоб для bson

Answer 3

[Станислав Макаров]

Насколько плохой практикой является использование JSON в реляционных базах данных (это строго запрещено, иногда разрешается или это хороший тон)?

Настолько же, насколько и хранение картинок, а также текстов. Ну двухгиговое JSON-полотно наверное не стоит хранить, ну в остальном требования такие же, как ко всему остальному что хранится в реляционной БД:

Значение атрибута должно быть атомарным с точки зрения запросов к БД. И то это касается таких СУБД, которые JSON не поддерживают. Если СУБД поддерживает JSON - тогда только документация к СУБД ответит тебе, что там можно, а что - нет. Если значение неатомарно с точки зрения запросов - тогда нужно будет постоянно его собирать-разбирать, да и индексы нужные не факт что получится построить.

Но в реляционных всё странно — сам принцип реляционных баз данных говорит, что для одного поля строго одно значение

А тут я задам вам каверзный вопрос - строка это одно значение или нет? Почему это мы решили, что можно сохранить в атрибут строку? Я требую посимвольного разбития! Вам не приходило в голову, что сначала нужно крепко подумать над понятием "одно значение"? Что это вообще значит? А если хранится число с плавающей точкой - это одно значение или два?

Answer 4

[ThunderCat]

JSON это строка. Формат хранения позволяет хранить много значений разного типа в одной ячейке. Очевидно что активная работа с таким форматом будет не эффективна, так как каждая строка по сути может содержать совершенно различный набор внутри себя, что не есть хорошо для поиска.
С другой стороны, данные не критичные к поисковым выборкам (то есть по которым не будет производиться сравнение, объединение или сортировка) по сути строки, и на производительность влияют мало. А что нужно конкретно вам - из вопроса не ясно.

Comments

[Евгений Усачев]

Речь шла не о замене реляционности, а о хранении информации. Условно пропусков. В таблице у каждого человека есть пропуск, например, в спортзал. Этот пропуск имеет свои параметры ( например, дату истечения срока, уровень подписки и так далее). У каждого человека есть свой пропуск. Поиск или прочие операции по пропуску не могут происходить по сценарию. Так можно ли использовать тут JSON для того, чтобы прямо у пользователя сохранить его пропуск, а не создавать дополнительную таблицу?

[ThunderCat]

Евгений Усачев,

Поиск или прочие операции по пропуску не могут происходить по сценарию.

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

[Adamos]

ThunderCat,

то есть вы нигде ПОКА не проверяете

Obvious fix :)

[ThunderCat]

Adamos, В точку и вкусно )

[batyrmastyr]

ThunderCat, Adamos, Постгрес весьма неплохо умеет индексировать JSON.

Евгений Усачев, смотря насколько часто вам нужно получать пропуск вместе с пользователем. Всё же JSON хранит не только значения, но и ключи, сжатие из коробки отсутствует.
Из вашего описания напрашивается отдельная таблица, но и какой-то проблемы в json не вижу кроме нескольких моментов: 1) а могут ли действовать несколько пропусков у одного человека? 2) как делаете замену пропуска? 3) будете ли выяснять, чей месяц назад был пропуск N?

[Adamos]

batyrmastyr, а медведь после должной дрессировки вполне может сделать круг по манежу на велосипеде. Но зачем?

[batyrmastyr]

Adamos, чтобы я поржал с неподходящей аналогии.
Есть случаи, когда JSON либо лучшее решение (по трудозатратам/последствиям) либо меньшее из зол.

[Adamos]

batyrmastyr, боюсь, эти случаи оправданного использования JSON в БД тонут в океане использования JSON исключительно из-за бездарного, без учета нормализации, проектирования БД новичками.

[batyrmastyr]

Adamos, так и про денормализацию, и вообще про написание кода можно сказать. Предлагаете вместо написания кода страдать фобиями / охоту на ведьм устроить?

[Adamos]

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

[batyrmastyr]

Adamos, как по мне, лучше дать спички и сразу подпалить палец — надёжно запоминается как делать нельзя и, что важно, почему.
Если подпалить нельзя, то перечислить проблемы, а плюсы пусть ищет сам.

[Adamos]

batyrmastyr, на таком проекте, который доверят новичку - увы, не обожжется.
Приходится запугивать и угрожать авансом ;)

Answer 5

[Dimonchik]

у Вас немного узкие представления о базах, и Вы пытаетесь на мир их спроецировать

см 2018 комментировать не буду, но сама Arangodb тоже посмотрите
https://www.arangodb.com/2018/02/nosql-performance...

кратко - тип-начинка базы (и мускуль и постгре могут стать, внезапно, такими же быстрымы NoSQL базами при нужных модулях) определяется требованиями задачи

Answer 6

[Wan-Derer]

Я хранил в JSON цветовые схемы приложения (цвет фона, шрифта, фонт, размер и пр.). Так как манипуляции с данными внутри схемы -операция крайне редкая, я счёл что так можно. Можно было, конечно, разложить всё по полям, но мне показалось проще получать готовую схему и сразу её сохранять и отдавать так же.
Ещё в текстовых полях хранил пары ключ-значение, т.е. много пар в одном поле. Делал map.toString() и сохранял. Обратно в Map вытаскивал простым парсером.
Вроде никто драться не лез :)
Правда я тоже новичок и как правильно не знаю :)

Answer 7

[Vitsliputsli]

Можно, но с умом. При невысокой нагрузке, база данных скорее всего простит вам это. При высокой относитесь к json как к обычной строке, т.е. без всяких индексов и поисков по параметру внутри json, максимум когда выборка уже сделана, можно попросить СУБД выбрать нужный атрибут. Как бы PostgreSQL не агитировал за json, поиск по его внутренностям всегда будет хуже по производительности.

Answer 8

[Сергей]

Как уже заметили выше "скакать надо от печки", т.е. от данных , а не от инструмента или принято / не принято.

Вот пример их моей практики, где я использовал JSON (сначала в Mysql потом переехали на Postgres)

Заказчик присваивал атрибуты товарам и (!) их количество было переменным даже для одного типа. Например,
велосипед 1 (цвет, взрослым, подходит мужчинам женщинам, вес)
велосипед 2 (цвет, детям)
у одного велосипеда - два атрибута у другого - 20 (как производитель прислал) и потом по атрибутам заставил сделать фильтры на фронте.

Нормализовать это в реляционных терминах было бы неразумно - большинство полей в таблицах были бы дырками. А так, заказчик вносит редко, а выборка частая - индексация по отдельным json-полям существует в СУБД (ну или там виртуальные поля для программистов) - всё быстро.

Comments

[batyrmastyr]

Даже в такой схеме напрашивается какая-то нормализация атрибутов иначе поиск превращается в кошмар для пользователя: один производитель прислал размер носков 45, другой 43-45, а пользователь обязан выбрать в фильтре все варианты, чтобы найти 45-й размер.
То есть для поиска - реальные столбцы, а данные от производителя в JSON использовать для отображения.
Да и Постгрес довольно пофигистично смотрит на «дырки», лишь бы количество столбцов не уходило в космос.

[Сергей]

конечно, на входе атрибуты "чистятся".

ну выбрал пользователь 45 - ему и нашлись все, которые на его 45 налезут - что то не понял я вашего примера. Конкретно это и хранится как "допустимый размер" 45...45, 43...45 - все что в диапазон попало - получи.

грубо говоря:
{
"size": {
"min": 43,
"max: 45,
}
}

А так, динамический набор фильтров на сайте в зависимости от категории - не вижу никакого кошмара.

Отзывы на А/Б тестировании вполне себе положительные.

Да и движок на знает какой атрибут появится дополнительно - мы посчитали, что создавать столбцы в базе динамически не комильфо.