https://www.opennet.ru/openforum/vsluhforumID3/89621.html В состав находящейся в разработке ветки СУБД PostgreSQL 9.3 включен (http://michael.otacoo.com/postgresql-2/postgres-9-3-feature-highlight-json-operators/) набор средств для обработки данных в формате JSON. Если в ветке PostgreSQL 9.2 появилась поддержка типа данных JSON (http://www.postgresql.org/docs/9.2/static/datatype-json.html), обеспечивающего хранение данных в согласованном виде, то в PostgreSQL 9.3 появятся встроенные средства для преобразования и манипуляции данными в формате JSON.<br><br><br>Новые возможности можно разделить на две категории: <br><br><br>- Функции (http://michael.otacoo.com/postgresql-2/postgres-9-3-feature-highlight-json-data-generation/) для генерации данных в формате JSON из данных в других форматах: json_agg, to_json, hstore_to_json и hstore_to_json_loose;<br><br><br>&lt;font color="#461b7e"&gt;<br> postgres=# create table aa (a bool, b text);<br> CREATE TABLE<br> postgres=# INSERT INTO aa VALUES (true, 'Hello "Darling"');<br> INSERT 0 1<br> postgres=# INSERT INTO aa VALUES (false, NULL);<br> INSERT 0 1 https://www.opennet.ru/openforum/vsluhforumID3/89621.html#19 Sun, 28 Apr 2013 12:20:53 GMT &gt; Индексируются ведь значения. Строится функциональный индекс, если нужно что-то искать <br>&gt; опираясь на значение из этого поля. А вот необходимость опираться выборке <br>&gt; на неудобное - это на совести программиста.<br><br>Об этой отсутствующей у ряда RADов совести и речь. Лучше вообще эту функциональность не добавлять, ибо скатит код в сраное говно.<br> https://www.opennet.ru/openforum/vsluhforumID3/89621.html#18 Sun, 28 Apr 2013 12:19:21 GMT Индексируются ведь значения. Строится функциональный индекс, если нужно что-то искать опираясь на значение из этого поля. А вот необходимость опираться выборке на неудобное - это на совести программиста. <br> https://www.opennet.ru/openforum/vsluhforumID3/89621.html#17 Sun, 28 Apr 2013 12:15:28 GMT Пусть будет. То что не нужно само отвалиться со временем.<br> https://www.opennet.ru/openforum/vsluhforumID3/89621.html#16 Wed, 17 Apr 2013 03:33:08 GMT А если подумать, как это всё будет с индексами работать - то лучше нормально структурировать БД, а не изобретать жсоны.<br> https://www.opennet.ru/openforum/vsluhforumID3/89621.html#15 Wed, 17 Apr 2013 03:32:19 GMT Пщщщщщ... Кто ответит: зачем велосипеду лестница?<br>Такое впечатление, что некоторые проекты скатываются в маразм...<br><br>Я всё понимаю - тренды там, розовые лошади. Но КАК это индексировать? Некоторые ведь там начнут хранить половину таблицы, вместо нормального структурирования. А потом будем удивляться - почему очередная поделка не использует индексы и ворочается по году на каждый чих.<br> https://www.opennet.ru/openforum/vsluhforumID3/89621.html#14 Mon, 15 Apr 2013 19:39:21 GMT А парсить всё это надо перлом.<br> https://www.opennet.ru/openforum/vsluhforumID3/89621.html#13 Mon, 15 Apr 2013 19:31:40 GMT индексы строить гораздо эффективней на &#171;сырых&#187; данных и куда эффективней.<br><br>про JSON &#8212; думаю лучше пусть будет, чем нет.<br>пользоваться этой функциональностью никто не обязывает.<br> https://www.opennet.ru/openforum/vsluhforumID3/89621.html#12 Mon, 15 Apr 2013 15:18:34 GMT &gt; таблички тоже нужны, а в вашем случае проще сразу nosql-базой воспользоваться.<br><br>А как таблички связаны с NoSQL-ностью? :)<br> https://www.opennet.ru/openforum/vsluhforumID3/89621.html#11 Mon, 15 Apr 2013 15:17:46 GMT Если к SQL добавить JSON - получается весьма годный брейнфак.<br>