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

Я понимаю, что тут не может быть однозначного ответа, поэтому я хочу услышать скорее не ответ, а его объяснение. В не реляционных базах данных это считается хорошей практикой. Но в реляционных всё странно — сам принцип реляционных баз данных говорит, что для одного поля строго одно значение, однако в Postgresql поддерживается формат JSON, это объективно более производительное решение во многих случаях и некоторые медийные люди заявляют о необходимости таких решений.
Теперь несколько маленьких вопросов:
Можно ли использовать JSON формат, если нагрузка слишком большая или надо переходить на другую базу данных?
Насколько плохой практикой является использование JSON в реляционных базах данных (это строго запрещено, иногда разрешается или это хороший тон)?
  • Вопрос задан
  • 1017 просмотров
Решения вопроса 2
VladimirAndreev
@VladimirAndreev
php web dev
Если нет частых апдейтов поля с json - то вполне можно его использовать.
Кроме полей, которые под внешние ключи либо выборки.
Хорошо хранить данные, которые не имеют четкой структуры, либо эта структура может часто изменяться.
Например, результаты каких-нибудь сборов данных вполне можно хранить в jsonb-поле.
Ответ написан
Комментировать
saboteur_kiev
@saboteur_kiev
software engineer
В любом базе можно хранить. Вопрос в том, что проще - брать json из базы и парсить его внутри на нужные значения, или хранить все значения в отдельных полях в базе.
Это больше вопрос конкретного проекта и конкретного использования.
А так - со стороны базы - никаких проблем в этом нет. Можно хранить как text или блоб для bson
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 6
Насколько плохой практикой является использование JSON в реляционных базах данных (это строго запрещено, иногда разрешается или это хороший тон)?

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

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

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

А тут я задам вам каверзный вопрос - строка это одно значение или нет? Почему это мы решили, что можно сохранить в атрибут строку? Я требую посимвольного разбития! Вам не приходило в голову, что сначала нужно крепко подумать над понятием "одно значение"? Что это вообще значит? А если хранится число с плавающей точкой - это одно значение или два?
Ответ написан
Комментировать
ThunderCat
@ThunderCat
{PHP, MySql, HTML, JS, CSS} developer
JSON это строка. Формат хранения позволяет хранить много значений разного типа в одной ячейке. Очевидно что активная работа с таким форматом будет не эффективна, так как каждая строка по сути может содержать совершенно различный набор внутри себя, что не есть хорошо для поиска.
С другой стороны, данные не критичные к поисковым выборкам (то есть по которым не будет производиться сравнение, объединение или сортировка) по сути строки, и на производительность влияют мало. А что нужно конкретно вам - из вопроса не ясно.
Ответ написан
dimonchik2013
@dimonchik2013
non progredi est regredi
у Вас немного узкие представления о базах, и Вы пытаетесь на мир их спроецировать

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

кратко - тип-начинка базы (и мускуль и постгре могут стать, внезапно, такими же быстрымы NoSQL базами при нужных модулях) определяется требованиями задачи
Ответ написан
Комментировать
@Wan-Derer
Зобанели на Хабре, волки́ ;((
Я хранил в JSON цветовые схемы приложения (цвет фона, шрифта, фонт, размер и пр.). Так как манипуляции с данными внутри схемы -операция крайне редкая, я счёл что так можно. Можно было, конечно, разложить всё по полям, но мне показалось проще получать готовую схему и сразу её сохранять и отдавать так же.
Ещё в текстовых полях хранил пары ключ-значение, т.е. много пар в одном поле. Делал map.toString() и сохранял. Обратно в Map вытаскивал простым парсером.
Вроде никто драться не лез :)
Правда я тоже новичок и как правильно не знаю :)
Ответ написан
Комментировать
@Vitsliputsli
Можно, но с умом. При невысокой нагрузке, база данных скорее всего простит вам это. При высокой относитесь к json как к обычной строке, т.е. без всяких индексов и поисков по параметру внутри json, максимум когда выборка уже сделана, можно попросить СУБД выбрать нужный атрибут. Как бы PostgreSQL не агитировал за json, поиск по его внутренностям всегда будет хуже по производительности.
Ответ написан
Комментировать
dostrog
@dostrog
Как уже заметили выше "скакать надо от печки", т.е. от данных , а не от инструмента или принято / не принято.

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

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

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

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

Войти через центр авторизации
Похожие вопросы