Всем привет, впервые работаю с json, помогите пожалуйста решить проблему.

У меня в столбце json есть пропуск и при запуске этого кода:
(ml_requ::json->'phoneNumber') :: text
Выдает ошибку:
invalid input syntax for type json
Как здесь игнорировать пропуски или что может помочь?

Я бы что то типа https://www.postgresqltutorial.com/postgresql-coalesce/ использовал, можно конечно это https://www.postgresqltutorial.com/postgresql-case/ в общем есть где разгуляться

select ('{"phoneNumber": 6661313}'::json->'phoneNumber') :: text

ааа ты имел ввиду пропуски такие что ли? select (replace('{"phoneNumber": "666131 3"}', ' ', '')::json->'phoneNumber') :: text

Спасибо большое:)

Спасибо, разобрался;)

А еще я тут онлайн редактор нашел что позволяет быстро на основе кода проектировать отношения между таблицами, ранее спрашивал, вот нашел, отличное решение https://dbdiagram.io/d

У этих ребят (holistics.io) еще очень дешёвый bi tool есть, пишешь sql с макросами, получаешь репорты.

Хитрым образом позволяет формировать аналитику судя по лендингу?

да, там например можно сделать дропдаун из запроса, например company_name_filter = select name from companies group by 1 (это где то закешировалось) и потом в своих репортах писать select * from blabbla whenre company_name = %company_name_filter% and date > %date_filter% очень удобно, я в двух местах работы уже пользуют этим би, все ок. и цена просто смешная

Круть, попробую, спасибо

Я под аналитику решил хардкорный ELK стек изучить, много времени потратил на прочтение как это все дело работает, еще Loki посмотрел, в общем суть такова что планировал логгировать вообще все а потом уже детально настраивать если в будущем какие данные захочу подтянуть.

Так проблема то что в конце аналитики хотят клепать sql или просто драг н дропом собирать репорты никакой elk им не надо, вот тогда и нужны все эти bi tools типа holistics/looker/tableu/иже с ними

Elk это больше агрегация и дашборды, для анализа аналитики этого маловато

Я так понял Elastic или Promtail занимается разделением данных на индексируемые и все остальные которые можно будет фильтровать, logstash или Loki уже хранением данных занимаются, а чем их отображать уже дело последнее, я так понял этот продукт как раз отображением занимается. Суть ведь такова, что если проиндексируешь все то объемы будут огромны как хранимых данных так и оперативной памяти иначе сильно просядет скорость, по этому следует индексировать по уму и остальное фильтровать как я понял.

Для срезы аналитики и формы ее отображения это тоже важно, но аналитика будет крайне медленной без верных структур хранимых данных, индексы и прочее, но я могу ошибаться изучал только теорию

Да пихаешь все данные в aws redshift или greenplum и особо не паришься)

Дорого-богато выйдет)

+

Тогда кликхаус

В Loki для хранения используется boltdb

Что компании будет дешевле, накинуть пару серверов или нанимать вундеркиндов senior pomidor data engineer поддерживать ваш аналитический стек?

Это все базы занимаются. Ну, почти все.

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

Сильно зависит от компании и объемов данных )

Простите, а какие у вас объемы?) просто любопытно

Исключительно теоретические, но я знаю что "Ничто так не вечно как временное решение" так что думаю сразу привыкать отстраивать системы менее "прожорливыми" я если честно не могу свой проект продолжить делать так как просто не имею опыта в проектировании БД, то есть: 1 Функционал есть 2 Понимание как базы создавать в виде синтаксиса есть А вот как разбить это все на нужные таблицы и завязать понимания нет, но подразумеваю что нужно отталкиваться от функционала 😁 ранее на ORM джанги делал совсем простые решения, вот настоящая проблема а не это все)

Преждевременная оптимизация - корень всех зол :) один умный дядя в книжке писал)

Особенно если это MVP стартапа )

Только а обратную сторону то же скатываться не надо

https://sqldbm.com/Home/ вот этот тоже неплохой, тут вообще без кода

Если вы работаете со стэком ELK — то там (конкретно — в БД ElasticSearch) такого понятия, как "таблица", нет Обычно (в моей практике, по-крайней мере) в ES, работающей для сбора логов (трейсов и проч), создают несколько "индексов" (условно — "баз данных" если использовать терминологию РСУБД), и направляют логи, в зависимости от их типа, в разные индексы. Далее на каждый индекс настраиваются правила их ротации: какие-то некритичные трейсы, например, хранятся месяц, что-то важное — дольше (или вообще не удаляется) Перед зачисткой трейсов их можно, если такая информация может потребоваться, как-то сагрегировать ("схлопнтуь"). Так, чтобы каждый чих хранился вечно — так не встречал, не вся и не всегда информация из логов важна в долгосрочной перспективе

Я тоже в контексте Elastic не встречал понятия "таблицы", встречал мануалы где рассматривалось постоянное хранение, описано интересно конечно 😁