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

Возможно ли во время запроса SELECT получить данные из json и выдать результат?
ИЛИ лучше написать функцию?
Или дублировать детали все же в другую таблицу?

qwwqразвидеть это
с какой стороны не посмотрел на эту фразу так и не понял смысла. объяснитесь пожалуйста

Используется PG 9.3

Sergei.AgalakovОдно непонятно - почему при таком подходе вы выбрали Postgres, а не Mongo, Redis etc. - тысячи их. Я не спорю с подходом, но выбор Postgres как базы для работы с JSON и только JSON мне непонятен.
Обосновать можно?
База была выбрана около года назад, на ней все и начали строить. Про Mongo я и не знал тогда.
В базе не только json есть. Json я использую для удобного сохранения заказов и удобной в первую очередь загрузки заказов, тяжелая структура у деталей.

ec2crauseВозможно ли во время запроса SELECT получить данные из json и выдать результат?


Напишите подробнее с примерами, что вы хотите.


Возможно ли такое? И на сколько глючно и медленно оно будет работать?

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

Хранить заказ и все его свойства я планировал в поле text, но текст там будет содержатся в виде json.
Объясняю почему json.
Есть объект "Заказ" в объект "ЗАКАз" входят еще объекты а вних еще объекты.
у этого объекта 10 свойств которые заполняет клиент.
Потом клиент выбирает изделие, в зависимости от размера меняется количество деталей, тип деталей их размеры считаются в зависимости от размеров и наличии других деталей. У изделия есть еще 10 объектов. У каждого из 10 объектов есть еще минимум 3 объекта и максимальное кол-во 5 объектов. с различными свойствами. В дальнейшем планируют нововведения и количество объектов увеличиться. Все свойства в объектах заполняются автоматически, но 90% клиентов перезаполняют 70% свойств объектов своими разными данными.

Что бы сохранить все эти объекты и их значения не плохо надо поломать мозг над кодом, а также над базой.
По мне гораздо проще в объект встроить TJson и формировать структуру объектов в json, соответственно легче сохранять и загружать.

Т.е. База только хранит в себе текcт json.

qwwq мордописец (см. профиль умельца)
Ху из мордописец?

rovancrauseЧто бы сохранить все эти объекты и их значения не плохо надо поломать мозг над кодом, а также над базой.
Не надо мозг ломать, надо структуру базы и процессы проектировать. Обычная задача.
Дело твоё, конечно, хочешь - развлекайся с джейсоном. Если больших нагрузок не предполагается - всё будет работать удовлетворительно, полагаю.

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

Суть поиска в JSON в том что:
какая-то деталь может остаться на складе (человеческий фактор)
может быть брак

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

Sergei.Agalakov,
читал сегодня как раз. склоняюсь еще к тому что, буду дублировать необходимые данные в поля