8 марта 2011 г. 0:47 пользователь Dmitriy Igrishin <dmitigr@gmail.com> написал:
8 марта 2011 г. 0:39 пользователь Dmitry E. Oboukhov <unera@debian.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'ы.
Уникальные ключи в измерениях? Можно пример, очень интересно. А ещё интереснее было бы взглянуть на пример с вн. ключами.
можно было бы по добавлении записи в любую таблицу пересчет общей статистики делать, но это накладно, поэтому вот такая схема как я выше нарисовал используется --