Pull to refresh

Comments 15

Буквально вчера писал запрос чтоб обновить сразу несколько значений в json записях. Причём ключи заранее не известны - обновлять нужно только те у которых значение подходит под условие. Намучался. Синтаксис весьма громозкий и плохо читаемый. Работать с json в реляционных БД можно, но удовольствия это не приносит.

Соглашусь, удовольствие - так себе. Но надо признать, что в целом работа с json возможна и достаточно эффективна по сравнению с большим количеством join-ов (это отсылка к статье "Замена EAV на JSONB в PostgreSQL").

А если сериализация в байтокд и блоб ячейки в скульнике?

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

Все же зависит от подхода что и как вы храните в байткоде.

Что автор хранит рассказано в статье.

имхо сложно - (upadate, delete... jsonb)
Зачем в Pg хранить сущности, когда они уже есть в OpenSearch, возможно проще будет в Pg держать команды (upadate, delete..) и через Kafka обновлять OpenSearch?

Хм... Звучит интересно. Надо подумать. В нашем проекте, естественно, не такая примитивная логика - она сопряжена с возможностью сохранения черновиков товаров, валидацией информации, взаимодействием со сторонними ресурсами, поэтому пока не могу однозначно сказать, что будет ли достаточно хранения в Postgres только команд, а не сущностей.

Прежде чем изобретать модель данных имеет смысл поискать готовый взвешенный референс. Хотя бы чтобы не наступить на грабли, о существовании которых другие уже знают и нашли решение. Тем более для Ритейла есть очень качественная референсная модель https://www.omg.org/retail-depository/arts-odm-73/

EAV – понятное дело, считается антипаттерном в большинстве профессионального сообщества. В данном случае я бы смотрел в сторону Anchor Modeling в postgresql в качестве хранилища данных + любая NoSQL СУБД (а можно и тот же postgresql + jsonb) в качестве витрины данных.

Почитал, почему считается что это АП. Конечно там умные люди пишут, не то что я. Но у меня, например, есть ПО, в котором в ЛЮБОЙ момент пользователь может изменить структуру сущности, есть калькулируемые атрибуты, есть атрибуты которые должно быть видны или скрыты. Обычными реляшками это не решить. У меня просто физически нет другого подхода. АП же он считается когда подход начинают пихать везде. Ну и большая часть significant disadvantages Отсюда уже давно не проблема, ну или имеет обходные пути решения

Хотел добавить. Я всегда работаю с сущностями на проекте таким образом: сущность ВСЕГДА выбирается ВСЯ по id, валидируется по политикам, измениться/добавиться/удалиться может любой столбец или набор столбцов, сущность сохраняется, опять же таки, вся. У меня нет ни фильтров по атрибутам, ни балковых операций. Поэтому EAV мне отлично подходит. Но проблема начинается у того, кому лень статичные данные описывать в реляционной модели (сущности у которых сотни и тысячи колонок), но ему нужно работать с ними как с реляционными таблицами: фильтры по колонкам, констрейнты на колонки, уникальные индексы и т.д. Вот тогда EAV превращается в АП

Хотел бы обратить ваше внимание на вторую часть моего комментария:) Я написал про Anchor Modeling, в котором как раз в любой момент пользователь может изменить структуру сущности, и все остальные требования, которые вы перечислили, при этом всё это отлично ложится в традиционную реляционную модель и отсутствуют все недостатки EAV.

Как мнение: То, что можно продать, должно лежать в одной таблице и иметь свой id. То, что программистам лень/не удобно/долго добавлять множество свойств товара - это проблема программистов, а не структуры данных. Задача с множествами размеров, цветов и тд решается простым id_parent на себя саму. Это решает множество проблем при учёте товаров в бухгалтерии, экспорте, импорте и тп. Хранение же данных в json можно рассмотреть как вариант кеширования.

Sign up to leave a comment.

Articles

Change theme settings