The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Для PostgreSQL 9.3 подготовлены полноценные средства для раб..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Для PostgreSQL 9.3 подготовлены полноценные средства для раб..."  +/
Сообщение от opennews (??) on 15-Апр-13, 09:57 
В состав находящейся в разработке ветки СУБД 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-.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=36700

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Для PostgreSQL 9.3 подготовлены полноценные средства для раб..."  +8 +/
Сообщение от max (??) on 15-Апр-13, 09:57 
Не знаю даже, хорошо это или плохо. С одной стороны все идет к вебизации и/или жаваскриптизации, но я как то привык что база данных должна делать лишь CRUD и не более, и делать она должна это хорошо, а все остальное дело рук программиста, как и в какой виде предоставлять данные из базы, а может старею, черт его знает... :-(
В целом хотел сказать, лично я не знаю даже как к этому отнестись...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Для PostgreSQL 9.3 подготовлены полноценные средства для раб..."  +/
Сообщение от бедный буратино (ok) on 15-Апр-13, 10:10 
> Не знаю даже, хорошо это или плохо. С одной стороны все идет
> к вебизации и/или жаваскриптизации, но я как то привык что база
> данных должна делать лишь CRUD и не более, и делать она
> должна это хорошо, а все остальное дело рук программиста, как и
> в какой виде предоставлять данные из базы, а может старею, черт
> его знает... :-(
> В целом хотел сказать, лично я не знаю даже как к этому
> отнестись...

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

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

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

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


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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Для PostgreSQL 9.3 подготовлены полноценные средства для раб..."  –1 +/
Сообщение от hummermania (ok) on 15-Апр-13, 10:22 
Плюс к хранению данных в JSON формате - снижение зависимости от схемы данных. Особенно когда необходимо хранить в базе документы, у которых время от времени меняется набор полей и иерархия. Очень актуально в условиях часто меняющегося законодательства. В реляционной БД частое изменение схемы данных ведет к усложению структуры таблиц. А при хранении документов в подобном формате приколы поджидают только в момент поиска. Но тут уже MapReduce в помощь. Одна кстати из причина массового появления NoSQL хранилищ - отвязка от схемы.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "Для PostgreSQL 9.3 подготовлены полноценные средства для раб..."  +/
Сообщение от бедный буратино (ok) on 15-Апр-13, 10:37 
> Плюс к хранению данных в JSON формате - снижение зависимости от схемы
> данных. Особенно когда необходимо хранить в базе документы, у которых время
> от времени меняется набор полей и иерархия. Очень актуально в условиях
> часто меняющегося законодательства. В реляционной БД частое изменение схемы данных ведет
> к усложению структуры таблиц. А при хранении документов в подобном формате
> приколы поджидают только в момент поиска. Но тут уже MapReduce в
> помощь. Одна кстати из причина массового появления NoSQL хранилищ - отвязка
> от схемы.

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

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

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

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Для PostgreSQL 9.3 подготовлены полноценные средства для раб..."  –1 +/
Сообщение от hummermania (ok) on 15-Апр-13, 10:48 
Пусть будет поддержка JSON в PostgreSQL. На случай когда много жирного легаси завязано под RDBMS и есть необходимость немного облегчить задачу хранения в нереляционном формате. Ну и насчет сразу юзать NoSQL - конечно я согласен. Более того, я больше на стороне NoSQL баз. И за совместное их применение в проектах. Давно уже пора перестать бояться поддерживать в проекте компоненты разной архитектуры, тем более если каждый применять для решения своей задачи.  
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

12. "Для PostgreSQL 9.3 подготовлены полноценные средства для раб..."  +/
Сообщение от Аноним (??) on 15-Апр-13, 19:18 
> таблички тоже нужны, а в вашем случае проще сразу nosql-базой воспользоваться.

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

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Для PostgreSQL 9.3 подготовлены полноценные средства для раб..."  +2 +/
Сообщение от ip1981 (ok) on 15-Апр-13, 13:48 
Блджад! JSON - это формат представления, а не хранения.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

7. "Для PostgreSQL 9.3 подготовлены полноценные средства для раб..."  –1 +/
Сообщение от hummermania (ok) on 15-Апр-13, 15:38 
CouchDB не? Представления да, но и хранения тож, с учетом некоторых особенностей конечно.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Для PostgreSQL 9.3 подготовлены полноценные средства для раб..."  +/
Сообщение от бедный буратино (ok) on 15-Апр-13, 15:49 
> CouchDB не? Представления да, но и хранения тож, с учетом некоторых особенностей  конечно.

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

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

10. "Для PostgreSQL 9.3 подготовлены полноценные средства для раб..."  +/
Сообщение от Игрулькин on 15-Апр-13, 15:54 
Глупый формализм. JSON - это строковый формат, позволяющий засунуть в него любые структурированные данные. Какая разница, кто, что и как "представляет"?
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

13. "Для PostgreSQL 9.3 подготовлены полноценные средства для раб..."  –1 +/
Сообщение от ананим on 15-Апр-13, 23:31 
индексы строить гораздо эффективней на «сырых» данных и куда эффективней.

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

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

9. "Для PostgreSQL 9.3 подготовлены полноценные средства для раб..."  +/
Сообщение от Игрулькин on 15-Апр-13, 15:50 
Крайне прогрессивное решение! У меня в куче баз хранятся именно JSON-данные, позволяющие в одно поле совать гетерогенную инфу (например, логи защиты, операций, системные события). Делать три таблицы под каждый тип - неудобно, а создавать безликое varchar просто с текстом события - бессмысленно. JSON тут бесподобен, а если ещё на нём можно делать выборку, вообще киллер-фича!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "Для PostgreSQL 9.3 подготовлены полноценные средства для раб..."  +2 +/
Сообщение от AlexAT (ok) on 17-Апр-13, 07:33 
А если подумать, как это всё будет с индексами работать - то лучше нормально структурировать БД, а не изобретать жсоны.
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "Для PostgreSQL 9.3 подготовлены полноценные средства для раб..."  +3 +/
Сообщение от Аноним (??) on 15-Апр-13, 19:17 
Если к SQL добавить JSON - получается весьма годный брейнфак.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "Для PostgreSQL 9.3 подготовлены полноценные средства для раб..."  +1 +/
Сообщение от dxd on 15-Апр-13, 23:39 
А парсить всё это надо перлом.
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

15. "Для PostgreSQL 9.3 подготовлены полноценные средства для раб..."  +1 +/
Сообщение от AlexAT (ok) on 17-Апр-13, 07:32 
Пщщщщщ... Кто ответит: зачем велосипеду лестница?
Такое впечатление, что некоторые проекты скатываются в маразм...

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Для PostgreSQL 9.3 подготовлены полноценные средства для раб..."  +/
Сообщение от Аноним email(??) on 28-Апр-13, 16:19 
Индексируются ведь значения. Строится функциональный индекс, если нужно что-то искать опираясь на значение из этого поля. А вот необходимость опираться выборке на неудобное - это на совести программиста.  
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

19. "Для PostgreSQL 9.3 подготовлены полноценные средства для раб..."  +/
Сообщение от AlexAT (ok) on 28-Апр-13, 16:20 
> Индексируются ведь значения. Строится функциональный индекс, если нужно что-то искать
> опираясь на значение из этого поля. А вот необходимость опираться выборке
> на неудобное - это на совести программиста.

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

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

17. "Хорошо"  +/
Сообщение от Аноним email(??) on 28-Апр-13, 16:15 
Пусть будет. То что не нужно само отвалиться со временем.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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