SB
Был бы рад ссылки на документацию или если вам не сложно подсказать как такое реализовать
Size: a a a
2020 May 31
2_
jsonb_path_query(positions, '$[*] ? (@.client == 1)') вы их и так достаете.
SB
2flower _
jsonb_path_query(positions, '$[*] ? (@.client == 1)') вы их и так достаете.
Мне нужны именно значени и чтоб была возможность привести их к другому типу
2_
можно сделать еще один уровень подзапросов, можно перенести в with с cte вариантов много
2_
So Byte
Мне нужны именно значени и чтоб была возможность привести их к другому типу
я понимаю. но три раза ходить в магазин за 3 продуктами-это не правильно.
2_
я вообще не вижу в вашем кейсе пока необходимость json все данные плоские,
это как раз то с чем классика отлично работает.
это как раз то с чем классика отлично работает.
YS
Alexander Nikitin
Я не предлагал обсуждать свойства дампов (rto, возможные мины и так далее) я просто недоумевал почему люди спорят с документацией, в которой чёрным-по-белому написано: pg_dump — это программа для создания резервных копий базы данных PostgreSQL. Ещё раз, я не говорю, что дамп это круто и он нас всех спасёт, но говорить, что это не бэкап на мой взгляд это не правильно.
Потому что документация написана не DBA и не является неоспоримой истиной.
> в общем, это скорее вопрос терминологии
В общем, насколько я знаю, то, что backup — инструмент для DR (для которого критичными являются RTO и RPO, например), является общепринятым понимаем.
> Я не предлагал обсуждать свойства дампов
А давайте всё-таки обсудим.
Если Вы возьмёте и перепишете базу ручкой на бумагу (побайтово, к примеру) — это backup, подходит для DR, всё нормально?
Вот с дампами есть схожие проблемы.
> в общем, это скорее вопрос терминологии
В общем, насколько я знаю, то, что backup — инструмент для DR (для которого критичными являются RTO и RPO, например), является общепринятым понимаем.
> Я не предлагал обсуждать свойства дампов
А давайте всё-таки обсудим.
Если Вы возьмёте и перепишете базу ручкой на бумагу (побайтово, к примеру) — это backup, подходит для DR, всё нормально?
Вот с дампами есть схожие проблемы.
Ð
So Byte
Я уже не первый раз переписываю этот момент. И хранение в JSONB этих данных самый оптимальный вариант
святая простота, а люди полвека мучились и не знали про жсон, какую-то реляционную алгебру выдумали
Ð
2flower _
вы не обижайтесь, но для меня
>>Я не силен в БД запросах
и
>>И хранение в JSONB этих данных самый оптимальный вариант
не совместимо, хотя я тоже любитель по джейсонить в уголку.
>>Я не силен в БД запросах
и
>>И хранение в JSONB этих данных самый оптимальный вариант
не совместимо, хотя я тоже любитель по джейсонить в уголку.
это как раз таки очень часто совместно идущие в ногу качества
SM
пожалуйста, подскажите, можно ли как-то восстановить данные в таблице после DELETE FROM table?
l
конечно, из бекапа
Ð
пожалуйста, подскажите, можно ли как-то восстановить данные в таблице после DELETE FROM table?
откатить из архива до точки где был delete
SM
так
а если БД на heroku?
а если БД на heroku?
Ð
тогда надо узнавать у техподдержки хероки, видимо 🤷♂️
l
но, ето конечно оч кривой способ
l
и это конкретно для ГП, для постгри нужно искать
SM
да, к сожалению, от обычного пользователя это не доступно
P
Приветсвую, есть вопрос: как лучше хранить облако тегов к статье? В жсон пихать или делать справочник и кростаблицу?
Ð
да, к сожалению, от обычного пользователя это не доступно
нафига это обычному юзеру? если это часть бл, должна быть таблица-журнал, можно даже на триггере on delete