Re: [pgsql-ru-general] Re: [pgsql-ru-general] Хранимая процедура: возврат строки разного формата

8 марта 2011 г. 0:47 пользователь Dmitriy Igrishin <dmitigr(at)gmail(dot)com>написал:

>
>
> 8 марта 2011 г. 0:39 пользователь Dmitry E. Oboukhov <unera(at)debian(dot)org>написал:
>
>
>> DI> Хороший пример задачи, где можно применить hstore.
>> DI> Решение.
>> DI> CREATE TABLE device(id serial not null primary key, name text not
>> null); --
>> DI> усройство
>> DI> CREATE TABLE measurement(id serial not null primary key,
>> DI> device integer not null references device(id),
>> DI> mtime timestamp not null default now(),
>> DI> data hstore not null) ; -- измерение
>>
>> DI> Итого: 2 сущности - "устройство" и "измерение". Никаких объединений с
>> pg_class.
>>
>> кабы было все так просто то и не стоило бы огород городить :) я тут
>> просто задачу сильно упрощаю по отношению к реальной когда формулирую.
>>
>> на самом деле данные не удаляются, а помечаются как обработанные это
>> раз.
>>
>> а во вторых по каждой из дочерних таблиц построены свои индексы/отчеты
>> итп. то есть их не получается просто взять и в кучу соединить: как
>> минимум эффективные индексы потеряем (в т. ч. и уникальные)
>>
> Данные hstore индексируются с помощью GIST или GIN.
>
В догонку, начиная с 9.0, hstore может индексироваться и с помощью
BTREE и HASH, что позволяет строить даже уникальные индексы.
А ещё можно строить индесы (в т.ч. и уникальные) на выражения.
Например, так
create unique index m_idx1 on measurement using btree((data->'a'));
Это позволит сделать данные ключа 'a' уникальными.

>
>
>>
>> то есть если мы перейдем к hstore, то получим способ записи/хранения,
>> но потеряем способы выборки. для хешей одного типа нужен индекс по
>> key1, для хешей другого типа по key2, для третьего - уникальный ключ
>> по key3 и key4, плюс еще CHECK'и а так же некоторые измерения имеют
>> друг на друга FOREIGN'ы.
>>
> Уникальные ключи в измерениях? Можно пример, очень интересно.
> А ещё интереснее было бы взглянуть на пример с вн. ключами.
>
>
>>
>> можно было бы по добавлении записи в любую таблицу пересчет общей
>> статистики делать, но это накладно, поэтому вот такая схема как я выше
>> нарисовал используется
>> --
>>
>> . ''`. Dmitry E. Oboukhov
>> : :’ : email: unera(at)debian(dot)org jabber://UNera(at)uvw(dot)ru
>> `. `~’ GPGKey: 1024D / F8E26537 2006-11-21
>> `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
>>
>
>
>
> --
> // Dmitriy.
>
>
>

--
// Dmitriy.