[Nikita]

Привет
При использовании СУБД запросов можно выполнять обработку данных на лету.
Плюсы:
1. программы становятся короче
2. процесс обработки на порядки быстрее.
3. надежность повышается.
Минусы:
1. языки программирования гибче чем запросы СУБД
2. сложный алгоритм трудно втиснуть в СУБД запрос

Что вы скажете об этом методе ?
До этого пытался писать "СУБД програмки" при помощи языка который присутствует в MySQL вроде с пятой версии. Но из-за дефицита внутренних средств, и малой универсальности идея провалилась.
Пример программы

[Nikita]

Или вот этот запрос.

SELECT

date_format(nanm_cor.time, '%Y-%m-%d_%H:%i:%s'), 100*SUM(nanm_cor.C3)/(1137.7923*10), 100*SUM(nanm_pressure_corrected.C3)/(1084.3874*10), 100*SUM(arnm_cor.C3)/(2599.4737*10), 100*SUM(snt_pressure_corrected.C1)/(8246.9080*10), 100*SUM(snt_pressure_corrected.C2)/(2058.9606*10), 100*SUM(snt_pressure_corrected.C5)/(18055.5986*10), 100*SUM(snt_pressure_corrected.C6)/(23976.5679*10), 100*SUM(snt_cor.C63)/(826.5355*10), 100*SUM(snt_cor.C64)/(328.5460*10)

INTO OUTFILE

'/var/www/crdlx1/DVIN/temp/.tmp'

FROM

nanm_cor, nanm_pressure_corrected, arnm_cor, snt_pressure_corrected

WHERE

(nanm_cor.time BETWEEN 20050119000000 AND 20050119190000) AND (nanm_cor.time = nanm_pressure_corrected.time) AND (nanm_cor.time = arnm_cor.time) AND (nanm_cor.time = snt_pressure_corrected.time) AND (nanm_cor.time = snt_pressure_corrected.time) AND (nanm_cor.time = snt_pressure_corrected.time) AND (nanm_cor.time = snt_pressure_corrected.time) AND (nanm_cor.time = snt_cor.time) AND (nanm_cor.time = snt_cor.time)

GROUP BY

floor(UNIX_TIMESTAMP(nanm_cor.time)/600)

[W_z_rd]

Neodnoznachniy vopros. Nado reshat` isxodya iz situacii. V zavisimosti ot organizacii DB slozhnie voprosi mogut okazat`sya ochen` dorogostoyashimi dlya DB. Eto uzhe pochti iskusstvo - sostavlyat` slozhnie effektivnie zaprosi i pravil`no organizovivat` DB, znayu po svoemu opitu. S drugoy storoni, perekachka bolshix ob'emov dannik po seti - delo neblagodarnoe. IMHO - uslozhneniyami zaprosov sleduet dobit`sya tol`ko minimizacii trafika, a ostal`noe delat` "u sebya". T.e. esli, k primeru, est` vozmozhnost` sdelat` predvaritel`nuyu vyborku, skazhem, iz 1000 records v bol`shoy baze, to posleduyushiy analiz luchshe delat` sredstvami yazika programmirovaniya.
Kstati, oshibki v programme sushestvenno legche obnaruzhivat`/ustranyat`, chem oshibki v bol`shix scriptax.

[nm]

команда mysql EXPLAIN
а дальше benchmark ... руками .

(nanm_cor.time BETWEEN 20050119000000 AND 20050119190000)
AND (nanm_cor.time = nanm_pressure_corrected.time)
AND (nanm_cor.time = arnm_cor.time)
AND (nanm_cor.time = snt_pressure_corrected.time)
AND (nanm_cor.time = snt_pressure_corrected.time)
AND (nanm_cor.time = snt_pressure_corrected.time)
AND (nanm_cor.time = snt_pressure_corrected.time)
AND (nanm_cor.time = snt_cor.time)
AND (nanm_cor.time = snt_cor.time)

ну ты дядь , силен .... либо mysql с первого раза не понимает уже ?

в данном случае наверно будет быстрее делать обработку в SQL

[Nikita]

NM:
а я и не заметил
это у меня PHP эту дрянь генерирует
данке шон !

[Nikita]

Сорри
Забыл
Вотрой запрос, в котором я ошибся ...
Я вынужден был так сделать
мне в WWW нуобходимо графики строить, а перед этим еще и обрабатывать их ...
вовщем в среднем около 9-и Мегов временного ряда ...
До этого на Питоне делал потом С/С++ потом ROOT FRAMEWORK ...
Но тормозило по старшному ... одна только закачка всего этого добра в другое приложение.... вобщем можно было попить чашечку кофе ...

[Nikita]

Относительно трафика
Все это на одной машине находится ...

[nm]

нормализируйте данные, потом добавляйте избыточность, правьте /dev/hands в конце концов, ну йо.....