сикуель задачка

[dzher]

дано табличка фактов,
типа
[ (obj_id, measurement_id, dt (timestamp), value ]

нада для всех [(obj_id,measurement_id)] вынуть последнее значение.

решение влобь:

[T1 = select obj_id,mea_id,max(dt) from T group by obj_id,mea_id]

затем [join] Т1 с ишодной табличкой [on obj_id,mea_id,dt]

(солнце восходит и заходит ... т.е. работает все)

а другое решение есть ?

[Deesy]

а платформа?
но скорее всего именно так как описано выше.

[YellowMan]

Конечно есть

select value from T t1 left join T t2 on t1.obj_id=t2.obj_id and t1.mea_id=t2.mea_id and t1.dt<t2.dt
where
t2.dt is null

Можно почесать репу и написать два-три еще более странных запроса что будут работать. Но вот зачем?

Твой запрос медленно работает? Построй индекс по obj_id,mea_id,dt

[dzher]

Сообщение от Deesy

а платформа?

db2/aix

Сообщение от YellowMan

Твой запрос медленно работает

да - табличка большая 20+м записей
индекс создать низя - я там ни админ ниразу.
буду смотреть какие там индексы имеются.

[YellowMan]

Сообщение от dzher

буду смотреть какие там индексы имеются.

От этого и пляши или кидай их сюда - я прикину как оптимально написать.
Или найди одмина, у тебя там по-любому секционированние нулевое, всю таблицу перелопачивать все равно, так что новый индекс будет правильное решение.

[KaraNagai]

Наиболее оптимальное решение я думаю находится если немного в предметную область глянуть. Например, можно предположить, что очень просто ищется диапазон dt сильно меньший общего количетсва данных, в котором _точно_ будут значения value для _всех_ пар obj_id, measurement_id и сразу отсекать его.

[YellowMan]

Ты сам понял что сказал?

[tadpole]

Сообщение от KaraNagai

... и сразу отсекать его.

"Резать! К чёртовой матери! Не дожидаясь перетонита!" (c)

[Deesy]

надо смотреть выборку.
скорее всего 2 индекса (или один двойной) по id есть точно. а дальше смотреть сколько записей выдают пары obj_id, measurement_id а то вдруг там всего 2-3 строки получается, тогда все индексы по дате - идут лесом. если получается тысячи строк - тогда другой раскалд

[dzher]

отчет:
оставил изначальный вариант;
диапазон дат с"узить нельзя,
результат - 30+к записей (столь и должно быть).

в процессе борьбы выяснялось что:
- первая часть задачи не [real-time] , посему пофиг две минуты оно выполняется или десять.
- а вторая , [rt], решается другими стредствами ([mq])

всем спасиб.

[KaraNagai]

Ты сам понял что сказал?

вполне. например может оказаться что даже самое редко появляющееся значение там появлятется не реже чем раз в 10 минут. стало быть по таймстампу сразу режем всё что старше 10 минут (ну то есть соответствующие кондишны во все джойны и where прописываются) и всё начинает работать очень быстро. может быть

ещё один вариант - апдейтить эти значения в другой таблице (tblLastValues какая-нибудь) сразу при добавлении данных (по триггеру или запросом добавления).

[YellowMan]

Сообщение от KaraNagai

вполне. например может оказаться что даже самое редко появляющееся значение там появлятется не реже чем раз в 10 минут.

Может, да - а может и нет. По-любому пока последнюю запись не прочтешь - 100% уверенности нет. Мы же не Гугль какой-нибудь а серьезная RDMS

Сообщение от KaraNagai

ещё один вариант - апдейтить эти значения в другой таблице (tblLastValues какая-нибудь) сразу при добавлении данных (по триггеру или запросом добавления).

Можно и так - но в блокировочнике без гарантии "односессионности" записи это самый верный путь получить мертвую из-за локов базу. А в версионнике - нарваться на сообщение что опаньки, не могет быть более 30 версий одного и того-же, притормозите лошадь.
Это под серьезной нагрузкой - с десяток записей в секунду выдержут оба.

[KaraNagai]

Сообщение от YellowMan

По-любому пока последнюю запись не прочтешь - 100% уверенности нет.

такая уверенность может быть дана анализом требований и постановкой задачи. почему я и говорю - смотреть в предметную область.

Сообщение от YellowMan

но в блокировочнике без гарантии "односессионности" записи это самый верный путь получить мертвую из-за локов базу.

опять же надо смотреть постановку задачи. писать в эту табличку возможно будет один тред с одного девайса (по крайней мере так многие системы контроля производства делают - некая софтина на одном компе собирает данные с девайсов контролирующих датчики - синхронно или асинхронно, держит буфер и пишет из него уже в базу отдельным тредом)

[dzher]

продолжим ?

дано: табличка "узкая и длинная" - [obj_id,mea_id,ts,val]

надо: табличка "широкая и покороче" - [obj_id,mea_val1,mea_val2,...,mea_valN]
[ts] выкинут - патамучта все [mea_valX] - распоследние (см пост #1)

для малого кол-ва аттрибутов ([mea_id]-ей) делаем так:

[ select T1.obj_id, T1.val, T2.val, ... Tn.val from T1
join T2 on T1.obj_id=T2.obj_id
...
join Tn on T1.obj_id=Tn.obj_id
]

[Tx] - ет те самые конструкции с [max(ts)].

для бОльшего кол-ва аттрибутов можно сделать так:
(в ДБ2 аггрегируюшие функи типа [sum/avg...] пропускают пустые значения - [NULL])

[ select obj_id, sum(val1), ... sum(valN) from
(
select obj_id, val1, null, ... null from T1
union all
select obj_id, null, val2, ... null from T2
union all
...
select obj_id, null, null, ... valN from Tn
) group by obj_id
]

или вот так :
табличка-результат создается заранее (заведомо достаточний ширины)
[obj_id,mea_val1,...,mea_valNNN]

множество [mea_id]-ев известно и хранится в массивчике/spiske

"черная магия" (псеudокод):
[
for i in <mea_id list> do
merge into RESULT_TABLE r using
(select obj_id,val from T where mea_id=$i) a
on r.obj_id=a.obj_id
when matched then update set mea_val$i = a.val
else insert (obj_id,mea_val$i) values (a.obj_id,a.val)
end do;
]

now the Q - how do you do it ?

[YellowMan]

Сообщение от KaraNagai

такая уверенность может быть дана анализом требований и постановкой задачи

Ну аффтор как-то не удосужился выкатить нам тут ТЗ . А из того что он написал "нада для всех [(obj_id,measurement_id)] вынуть последнее значение" понятно только то что нада для всех. Для всех - значит для всех. Не нада думать - нада прыгать

Сообщение от KaraNagai

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

Так даже гугль с адвордсами делает - из-за чего у него на одной страничке одни циферки а на другой - другие.
Даже я так делаю - а у меня этих датчиков многие сотни тыщ - но опять-же про аффтора нам ничего не известно.
И строго говоря это есть избыточность что не всегда хорошо