8 марта 2011 г. 1:01 пользователь Dmitry E. Oboukhov
<unera@debian.org> написал:
DI> Данные hstore индексируются с помощью GIST или GIN.
а я вот с этими GIST и GIN не понял пока. где почитать про их
внутреннее устройство? интересует вопрос: если мы индекс по полю
hstore сделаем то насколько эффективность поиска пострадает по
сравнению с BTREE по выделенному столбику?
ну и некоторые столбики у меня бывает хранят массив значений (2-3)
то есть получится как бы хеш, но который в одном из своих полей (не
ключей) хранит массив. hstore справится с таким заданием? а построение
индекса по полю?
hstore хранит пары типа text - text. Любой тип данных или массив
можно привести к text.
DI> Уникальные ключи в измерениях? Можно пример, очень интересно.
есть и уникальные. фишка в том что некоторые измерители выдают
повторяющиеся результаты, а так же делают повторы передач если
посчитали что коннект с сервером не состоялся (канал плохой бывает
всякое)
соответственно есть уникальные индексы вида
идентификатор-устройства -- время когда было сделано измерение
В приведённой мною таблице measurement есть столбец mtime. Это
и есть момент измерения. Можно строить индекс (только сомневаюсь,
что есть необходимость строить уникальный индекс, если mtime
типа timestamp).
Другими словами, идея в том, чтобы поместить в hstore только
_данные_ измерений, а не свойста типа "время измерения", которые
являются метаданными по сути.
Индексы по данными измерения кажутся мне сомнительными...
на таблицу написано RULE, которое при приходе измерения которое уже
приходило ранее делает игнор (вернее запись в таблицу регистрации
трабел)
Тогда смысл в уникальных индексах (и т.п. ограничениях), если проверку
осуществляет правило?
DI> А ещё интереснее было бы взглянуть на пример с вн. ключами.
а это когда измеритель вылетает за установленный порог, то он
вызывает запуск другого измерителя, который в обычном режиме не
работает :) соответственно запись измерения еще ссылается на
идентификатор измерения по результатам которого инициировано сие
измерение. как-то так
Хорошо. В таблицы device и measurement добавляются столбцы parent,
который смотрит на столбец id (ссылка на себя). При этом, нужен
триггер на таблицу measurement для обеспечения соответствия
связей measurement - measurement и device - device - т.е. соответствия
связи данных и метаданных.
ну и комбинации вышеприведенного
--
. ''`. Dmitry E. Oboukhov
: :’ : email:
unera@debian.org jabber://
UNera@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
--
// Dmitriy.