The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]

15.04.2013 08:50  Для PostgreSQL 9.3 подготовлены полноценные средства для работы с JSON

В состав находящейся в разработке ветки СУБД PostgreSQL 9.3 включен набор средств для обработки данных в формате JSON. Если в ветке PostgreSQL 9.2 появилась поддержка типа данных JSON, обеспечивающего хранение данных в согласованном виде, то в PostgreSQL 9.3 появятся встроенные средства для преобразования и манипуляции данными в формате JSON.

Новые возможности можно разделить на две категории:

  • Функции для генерации данных в формате JSON из данных в других форматах: json_agg, to_json, hstore_to_json и hstore_to_json_loose;
    
       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)
    
    
     
  • Встроенные операторы и функции для обработки JSON-данных, позволяющие извлекать поля, менять отдельные значения, создавать записи на основе JSON-данных. В частности, для извлечения содержимого элементов JSON добавлены операторы "->", "->>", "#>" и "#>>".
    
    
       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)
    
    
  • Функции парсинга данных в формате JSON: json_each, json_each_text, json_extract_path, json_extract_path_text, json_object_keys, json_populate_record, json_populate_recordset, json_array_length, json_array_elements.

Для тех, кто желает начать использовать новые возможности не дожидаясь выхода PostgreSQL 9.3, указанные функции портированы для PostgreSQL 9.2 и опубликованы в форме внешнего дополнения.

  1. Главная ссылка к новости (http://michael.otacoo.com/post...)
  2. OpenNews: В PostgreSQL 9.3 появится поддержка операции UPDATE над представлениями
  3. OpenNews: Релиз СУБД PostgreSQL 9.2
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: postgresql, json
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, max (??), 09:57, 15/04/2013 [ответить] [показать ветку] [···]    [к модератору]
  • +8 +/
    Не знаю даже, хорошо это или плохо. С одной стороны все идет к вебизации и/или жаваскриптизации, но я как то привык что база данных должна делать лишь CRUD и не более, и делать она должна это хорошо, а все остальное дело рук программиста, как и в какой виде предоставлять данные из базы, а может старею, черт его знает... :-(
    В целом хотел сказать, лично я не знаю даже как к этому отнестись...
     
     
  • 2.2, бедный буратино (ok), 10:10, 15/04/2013 [^] [ответить]    [к модератору]
  • +/
    > Не знаю даже, хорошо это или плохо. С одной стороны все идет
    > к вебизации и/или жаваскриптизации, но я как то привык что база
    > данных должна делать лишь CRUD и не более, и делать она
    > должна это хорошо, а все остальное дело рук программиста, как и
    > в какой виде предоставлять данные из базы, а может старею, черт
    > его знает... :-(
    > В целом хотел сказать, лично я не знаю даже как к этому
    > отнестись...

    В json можно не только плоские данные выводить, как в обычной табличке, а с нормальной иерархией.

    А ещё json нагляден. И валидный json в 99% случаев - валидный аналогичный python-овый dict. И наоборот.

    json можно выразить текстом, понятным. Без этого данные от бд нужно сначала обрабатывать.

    Ещё бы браузеры бы без костылей типа jsonp научились бы json обрабатывать - вот это было бы вообще хорошо.


    И ещё. Для многих задач было бы достаточно бд + страница с js, без сервера (который в таких задачах занимается только преобразованием данных).

     
  • 2.3, hummermania (ok), 10:22, 15/04/2013 [^] [ответить]    [к модератору]
  • –1 +/
    Плюс к хранению данных в JSON формате - снижение зависимости от схемы данных. Особенно когда необходимо хранить в базе документы, у которых время от времени меняется набор полей и иерархия. Очень актуально в условиях часто меняющегося законодательства. В реляционной БД частое изменение схемы данных ведет к усложению структуры таблиц. А при хранении документов в подобном формате приколы поджидают только в момент поиска. Но тут уже MapReduce в помощь. Одна кстати из причина массового появления NoSQL хранилищ - отвязка от схемы.
     
     
  • 3.4, бедный буратино (ok), 10:37, 15/04/2013 [^] [ответить]    [к модератору]
  • +/
    > Плюс к хранению данных в JSON формате - снижение зависимости от схемы
    > данных. Особенно когда необходимо хранить в базе документы, у которых время
    > от времени меняется набор полей и иерархия. Очень актуально в условиях
    > часто меняющегося законодательства. В реляционной БД частое изменение схемы данных ведет
    > к усложению структуры таблиц. А при хранении документов в подобном формате
    > приколы поджидают только в момент поиска. Но тут уже MapReduce в
    > помощь. Одна кстати из причина массового появления NoSQL хранилищ - отвязка
    > от схемы.

    Это nosql базы и получаются, нет смысла из posgresql делать такую - таблички тоже нужны, а в вашем случае проще сразу nosql-базой воспользоваться.

    Но при выборках из плоских табличек по интересным запросам имеет смысл делать вывод именно в json, как упорядоченной структуре данных, вместо того, чтобы надёргать 10 табличек и вручную поля расставлять.

    Да и вообще - для json не нужен особый адаптер, можно хоть wget-ом опрашивать.

     
     
  • 4.5, hummermania (ok), 10:48, 15/04/2013 [^] [ответить]    [к модератору]
  • –1 +/
    Пусть будет поддержка JSON в PostgreSQL. На случай когда много жирного легаси завязано под RDBMS и есть необходимость немного облегчить задачу хранения в нереляционном формате. Ну и насчет сразу юзать NoSQL - конечно я согласен. Более того, я больше на стороне NoSQL баз. И за совместное их применение в проектах. Давно уже пора перестать бояться поддерживать в проекте компоненты разной архитектуры, тем более если каждый применять для решения своей задачи.  
     
  • 4.12, Аноним (-), 19:18, 15/04/2013 [^] [ответить]    [к модератору]  
  • +/
    > таблички тоже нужны, а в вашем случае проще сразу nosql-базой воспользоваться.

    А как таблички связаны с NoSQL-ностью? :)

     
  • 3.6, ip1981 (ok), 13:48, 15/04/2013 [^] [ответить]    [к модератору]  
  • +2 +/
    Блджад! JSON - это формат представления, а не хранения.
     
     
  • 4.7, hummermania (ok), 15:38, 15/04/2013 [^] [ответить]    [к модератору]  
  • –1 +/
    CouchDB не? Представления да, но и хранения тож, с учетом некоторых особенностей конечно.
     
     
  • 5.8, бедный буратино (ok), 15:49, 15/04/2013 [^] [ответить]    [к модератору]  
  • +/
    > CouchDB не? Представления да, но и хранения тож, с учетом некоторых особенностей  конечно.

    Тогда давайте и dict() вспомним. :)

     
  • 4.10, Игрулькин (?), 15:54, 15/04/2013 [^] [ответить]    [к модератору]  
  • +/
    Глупый формализм. JSON - это строковый формат, позволяющий засунуть в него любые структурированные данные. Какая разница, кто, что и как "представляет"?
     
     
  • 5.13, ананим (?), 23:31, 15/04/2013 [^] [ответить]    [к модератору]  
  • –1 +/
    индексы строить гораздо эффективней на «сырых» данных и куда эффективней.

    про JSON — думаю лучше пусть будет, чем нет.
    пользоваться этой функциональностью никто не обязывает.

     
  • 1.9, Игрулькин (?), 15:50, 15/04/2013 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Крайне прогрессивное решение! У меня в куче баз хранятся именно JSON-данные, позволяющие в одно поле совать гетерогенную инфу (например, логи защиты, операций, системные события). Делать три таблицы под каждый тип - неудобно, а создавать безликое varchar просто с текстом события - бессмысленно. JSON тут бесподобен, а если ещё на нём можно делать выборку, вообще киллер-фича!
     
     
  • 2.16, AlexAT (ok), 07:33, 17/04/2013 [^] [ответить]    [к модератору]  
  • +2 +/
    А если подумать, как это всё будет с индексами работать - то лучше нормально структурировать БД, а не изобретать жсоны.
     
  • 1.11, Аноним (-), 19:17, 15/04/2013 [ответить] [показать ветку] [···]    [к модератору]  
  • +3 +/
    Если к SQL добавить JSON - получается весьма годный брейнфак.
     
     
  • 2.14, dxd (?), 23:39, 15/04/2013 [^] [ответить]    [к модератору]  
  • +1 +/
    А парсить всё это надо перлом.
     
  • 1.15, AlexAT (ok), 07:32, 17/04/2013 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    Пщщщщщ... Кто ответит: зачем велосипеду лестница?
    Такое впечатление, что некоторые проекты скатываются в маразм...

    Я всё понимаю - тренды там, розовые лошади. Но КАК это индексировать? Некоторые ведь там начнут хранить половину таблицы, вместо нормального структурирования. А потом будем удивляться - почему очередная поделка не использует индексы и ворочается по году на каждый чих.

     
     
  • 2.18, Аноним (18), 16:19, 28/04/2013 [^] [ответить]     [к модератору]  
  • +/
    Индексируются ведь значения Строится функциональный индекс, если нужно что-то и... весь текст скрыт [показать]
     
     
  • 3.19, AlexAT (ok), 16:20, 28/04/2013 [^] [ответить]    [к модератору]  
  • +/
    > Индексируются ведь значения. Строится функциональный индекс, если нужно что-то искать
    > опираясь на значение из этого поля. А вот необходимость опираться выборке
    > на неудобное - это на совести программиста.

    Об этой отсутствующей у ряда RADов совести и речь. Лучше вообще эту функциональность не добавлять, ибо скатит код в сраное говно.

     
  • 1.17, Аноним (18), 16:15, 28/04/2013 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Пусть будет. То что не нужно само отвалиться со временем.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


      Закладки на сайте
      Проследить за страницей
    Created 1996-2018 by Maxim Chirkov  
    ДобавитьПоддержатьВебмастеруГИД  
    Hosting by Ihor