В состав находящейся в разработке ветки СУБД PostgreSQL 9.3 включен (http://michael.otacoo.com/postgresql-2/postgres-9-3-feature-.../) набор средств для обработки данных в формате JSON. Если в ветке PostgreSQL 9.2 появилась поддержка типа данных JSON (http://www.postgresql.org/docs/9.2/static/datatype-json.html), обеспечивающего хранение данных в согласованном виде, то в PostgreSQL 9.3 появятся встроенные средства для преобразования и манипуляции данными в формате JSON.
Новые возможности можно разделить на две категории:
- Функции (http://michael.otacoo.com/postgresql-2/postgres-9-3-feature-.../) для генерации данных в формате JSON из данных в других форматах: json_agg, to_json, hstore_to_json и hstore_to_json_loose;
<font color="#461b7e">
postgres=# create table aa (a bool, b text);
CREATE TABLE
postgres=# INSERT INTO aa VALUES (true, 'Hello "Darling"');
INSERT 0 1
postgres=# INSERT INTO aa VALUES (false, NULL);
INSERT 0 1
postgres=# SELECT to_json(a) AS bool_json, to_json(b) AS txt_json FROM aa;
bool_json | txt_json
-----------+---------------------
true | "Hello \"Darling\""
false |
(2 rows)postgres=# SELECT json_agg(aa) FROM aa;
json_agg
---------------------------------------
[{"a":true,"b":"Hello \"Darling\""}, +
{"a":false,"b":null}]
(1 row)
postgres=# CREATE TABLE aa (id int, txt hstore);
CREATE TABLE
postgres=# INSERT INTO aa VALUES (1, 'f1=>t, f2=>2, f3=>"Hi", f4=>NULL');
INSERT 0 1
postgres=# SELECT id, txt::json, hstore_to_json(txt) FROM aa;
id | txt | hstore_to_json
----+-----------------------------------+--------------------------------
1 | {"f1": "t", "f2": "2", "f3": "Hi", "f4": null} | {"f1": "t", "f2": "2", "f3": "Hi", "f4": null}
(1 row)</font>
- Встроенные операторы и функции для обработки JSON-данных, позволяющие извлекать поля, менять отдельные значения, создавать записи на основе JSON-данных. В частности, для извлечения содержимого элементов JSON добавлены операторы "->", "->>", "#>" и "#>>".
<font color="#461b7e">postgres=# SELECT b->>'f3' AS f1 FROM aa WHERE a = 1;
f1
----------------
Hi I'm "Daisy"
(1 row)
postgres=# SELECT b->'f3' AS f1 FROM aa WHERE a = 1;
f1
--------------------
"Hi I'm \"Daisy\""
(1 row)</font>
Для тех, кто желает начать использовать новые возможности не дожидаясь выхода PostgreSQL 9.3, указанные функции портированы (http://adpgtech.blogspot.de/2013/04/backport-of-93-json-enha...) для PostgreSQL 9.2 и опубликованы в форме внешнего дополнения (https://bitbucket.org/qooleot/json_enhancements).
URL: http://michael.otacoo.com/postgresql-2/postgres-9-3-feature-.../
Новость: http://www.opennet.me/opennews/art.shtml?num=36700
Не знаю даже, хорошо это или плохо. С одной стороны все идет к вебизации и/или жаваскриптизации, но я как то привык что база данных должна делать лишь CRUD и не более, и делать она должна это хорошо, а все остальное дело рук программиста, как и в какой виде предоставлять данные из базы, а может старею, черт его знает... :-(
В целом хотел сказать, лично я не знаю даже как к этому отнестись...
> Не знаю даже, хорошо это или плохо. С одной стороны все идет
> к вебизации и/или жаваскриптизации, но я как то привык что база
> данных должна делать лишь CRUD и не более, и делать она
> должна это хорошо, а все остальное дело рук программиста, как и
> в какой виде предоставлять данные из базы, а может старею, черт
> его знает... :-(
> В целом хотел сказать, лично я не знаю даже как к этому
> отнестись...В json можно не только плоские данные выводить, как в обычной табличке, а с нормальной иерархией.
А ещё json нагляден. И валидный json в 99% случаев - валидный аналогичный python-овый dict. И наоборот.
json можно выразить текстом, понятным. Без этого данные от бд нужно сначала обрабатывать.
Ещё бы браузеры бы без костылей типа jsonp научились бы json обрабатывать - вот это было бы вообще хорошо.
И ещё. Для многих задач было бы достаточно бд + страница с js, без сервера (который в таких задачах занимается только преобразованием данных).
Плюс к хранению данных в JSON формате - снижение зависимости от схемы данных. Особенно когда необходимо хранить в базе документы, у которых время от времени меняется набор полей и иерархия. Очень актуально в условиях часто меняющегося законодательства. В реляционной БД частое изменение схемы данных ведет к усложению структуры таблиц. А при хранении документов в подобном формате приколы поджидают только в момент поиска. Но тут уже MapReduce в помощь. Одна кстати из причина массового появления NoSQL хранилищ - отвязка от схемы.
> Плюс к хранению данных в JSON формате - снижение зависимости от схемы
> данных. Особенно когда необходимо хранить в базе документы, у которых время
> от времени меняется набор полей и иерархия. Очень актуально в условиях
> часто меняющегося законодательства. В реляционной БД частое изменение схемы данных ведет
> к усложению структуры таблиц. А при хранении документов в подобном формате
> приколы поджидают только в момент поиска. Но тут уже MapReduce в
> помощь. Одна кстати из причина массового появления NoSQL хранилищ - отвязка
> от схемы.Это nosql базы и получаются, нет смысла из posgresql делать такую - таблички тоже нужны, а в вашем случае проще сразу nosql-базой воспользоваться.
Но при выборках из плоских табличек по интересным запросам имеет смысл делать вывод именно в json, как упорядоченной структуре данных, вместо того, чтобы надёргать 10 табличек и вручную поля расставлять.
Да и вообще - для json не нужен особый адаптер, можно хоть wget-ом опрашивать.
Пусть будет поддержка JSON в PostgreSQL. На случай когда много жирного легаси завязано под RDBMS и есть необходимость немного облегчить задачу хранения в нереляционном формате. Ну и насчет сразу юзать NoSQL - конечно я согласен. Более того, я больше на стороне NoSQL баз. И за совместное их применение в проектах. Давно уже пора перестать бояться поддерживать в проекте компоненты разной архитектуры, тем более если каждый применять для решения своей задачи.
> таблички тоже нужны, а в вашем случае проще сразу nosql-базой воспользоваться.А как таблички связаны с NoSQL-ностью? :)
Блджад! JSON - это формат представления, а не хранения.
CouchDB не? Представления да, но и хранения тож, с учетом некоторых особенностей конечно.
> CouchDB не? Представления да, но и хранения тож, с учетом некоторых особенностей конечно.Тогда давайте и dict() вспомним. :)
Глупый формализм. JSON - это строковый формат, позволяющий засунуть в него любые структурированные данные. Какая разница, кто, что и как "представляет"?
индексы строить гораздо эффективней на «сырых» данных и куда эффективней.про JSON — думаю лучше пусть будет, чем нет.
пользоваться этой функциональностью никто не обязывает.
Крайне прогрессивное решение! У меня в куче баз хранятся именно JSON-данные, позволяющие в одно поле совать гетерогенную инфу (например, логи защиты, операций, системные события). Делать три таблицы под каждый тип - неудобно, а создавать безликое varchar просто с текстом события - бессмысленно. JSON тут бесподобен, а если ещё на нём можно делать выборку, вообще киллер-фича!
А если подумать, как это всё будет с индексами работать - то лучше нормально структурировать БД, а не изобретать жсоны.
Если к SQL добавить JSON - получается весьма годный брейнфак.
А парсить всё это надо перлом.
Пщщщщщ... Кто ответит: зачем велосипеду лестница?
Такое впечатление, что некоторые проекты скатываются в маразм...Я всё понимаю - тренды там, розовые лошади. Но КАК это индексировать? Некоторые ведь там начнут хранить половину таблицы, вместо нормального структурирования. А потом будем удивляться - почему очередная поделка не использует индексы и ворочается по году на каждый чих.
Индексируются ведь значения. Строится функциональный индекс, если нужно что-то искать опираясь на значение из этого поля. А вот необходимость опираться выборке на неудобное - это на совести программиста.
> Индексируются ведь значения. Строится функциональный индекс, если нужно что-то искать
> опираясь на значение из этого поля. А вот необходимость опираться выборке
> на неудобное - это на совести программиста.Об этой отсутствующей у ряда RADов совести и речь. Лучше вообще эту функциональность не добавлять, ибо скатит код в сраное говно.
Пусть будет. То что не нужно само отвалиться со временем.