SQL vs версионность-иммутабельность
Jun. 13th, 2012 12:11 pmА вот что бывает когда реляционные БД ставят в несвойственную им позу и нет моральных ограничений (потому что кодогенерация):
кусок запроса "получить информацию об последних изменениях в БД, поддерживающей хранение всей истории изменений".
Ситуация вообще в следующем:
1) Фактически я храню в БД персистентный граф, но морально отказаться от RDBMS/SQL и переписывать все с нуля я не готов. За вопросами - к
plumqqz, он вам расскажет, что думает за неосиливших СУБД.
2) N+1 запрос вообще и для Firebird в частности (сетевой протокол, лаги) - печаль. А то я бы всю сложность выкинул на клиента и там на F# собрал бы все что нужно. Впрочем, сервер и клиент (сервис-считалка) стоят рядом, ничего страшного, по идее, быть не должно.
3) В Firebird пока нет возможности сунуть код на произвольном языке в БД (как это есть у Postgres например)
PS: выяснил, чего сервер раком становится от таких запросов. Там дальше сортировка, не сводимая к чтению по индексам. Поэтому он начинает дичайше писать в временные файлы результат запроса и далее его читать. И файл размером 2 гига, внезапно, со скоростью 100 мег в секунду это таки 20 секунд на запись и потом хз сколько еще на фетч.
...
FROM REPLTRANS
join ChangeLog
left join TransactsLog tlog on tlog.TRANSACTS_CHL_ID=CHL_ID
left join TransactsLink tlnk
join Transacts tr on tr.TR_ID_BASEID=tlnk.TR_ID_BASEID and
tr.TR_ID_LOCALID=tlnk.TR_ID_LOCALID
left join Transacts tr_old on tr_old.TR_ID_BASEID=tr.TR_ID_BASEID_PV and
tr_old.TR_ID_LOCALID=tr.TR_ID_LOCALID_PV
on tlnk.TRANSACTS_CHL_ID=CHL_ID
left join FillingsLog filllog
join Customers cst1 on cst1.Cst_ID=filllog.FILL_Customer
on filllog.FILLINGS_CHL_ID=CHL_ID
left join FillingsLink filllnk
join Fillings fill
join Customers cst2 on cst2.Cst_ID=fill.FILL_Customer
on fill.FILL_ID_BASEID=filllnk.FILL_ID_BASEID and
fill.FILL_ID_LOCALID=filllnk.FILL_ID_LOCALID
on filllnk.FILLINGS_CHL_ID=CHL_ID
on (CHL_TRANS=REPLTR_BEGID+0)
join ReplTables on REPLTBL_ID=CHL_TABLE_ID
...
кусок запроса "получить информацию об последних изменениях в БД, поддерживающей хранение всей истории изменений".
Ситуация вообще в следующем:
1) Фактически я храню в БД персистентный граф, но морально отказаться от RDBMS/SQL и переписывать все с нуля я не готов. За вопросами - к
2) N+1 запрос вообще и для Firebird в частности (сетевой протокол, лаги) - печаль. А то я бы всю сложность выкинул на клиента и там на F# собрал бы все что нужно. Впрочем, сервер и клиент (сервис-считалка) стоят рядом, ничего страшного, по идее, быть не должно.
3) В Firebird пока нет возможности сунуть код на произвольном языке в БД (как это есть у Postgres например)
PS: выяснил, чего сервер раком становится от таких запросов. Там дальше сортировка, не сводимая к чтению по индексам. Поэтому он начинает дичайше писать в временные файлы результат запроса и далее его читать. И файл размером 2 гига, внезапно, со скоростью 100 мег в секунду это таки 20 секунд на запись и потом хз сколько еще на фетч.
no subject
Date: 2012-06-13 09:41 am (UTC)no subject
Date: 2012-06-13 09:47 am (UTC)на фронтза вопросами к plumqqzno subject
Date: 2012-06-13 09:44 am (UTC)no subject
Date: 2012-06-13 10:39 am (UTC)no subject
Date: 2012-06-13 10:46 am (UTC)no subject
Date: 2012-06-13 10:56 am (UTC)no subject
Date: 2012-06-13 10:06 am (UTC)это большой страшный запрос чтоле?
no subject
Date: 2012-06-13 12:53 pm (UTC)no subject
Date: 2012-06-14 02:27 am (UTC)С другой стороны в представленном запросе банальные джойны, еще и по, надеюсь, индексированным полям. Тут оптимизировать разве что порядок соединений.
(no subject)
From:no subject
Date: 2012-06-13 10:23 am (UTC)А что такое "морально отказаться"?
no subject
Date: 2012-06-13 10:42 am (UTC)no subject
Date: 2012-06-13 10:40 am (UTC)no subject
Date: 2012-06-13 11:04 am (UTC)no subject
Date: 2012-06-13 11:42 am (UTC)no subject
Date: 2012-06-13 12:04 pm (UTC)no subject
Date: 2012-06-13 10:42 am (UTC)PS Код в базе -- он у тебя будет "разъезжаться" с кодом в в гите (или чем тебе пауки велят пользоваться)
no subject
Date: 2012-06-13 11:04 am (UTC)(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2012-06-13 11:23 am (UTC)no subject
Date: 2012-06-13 11:27 am (UTC)(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2012-06-13 11:24 am (UTC)no subject
Date: 2012-06-13 11:29 am (UTC)(no subject)
From:no subject
Date: 2012-06-13 12:42 pm (UTC)сущноть, время_рождения_версии
надо хранить
сущноть, время_рождения_версии, время_смерти_версии
no subject
Date: 2012-06-13 12:54 pm (UTC)(no subject)
From:(no subject)
From:no subject
Date: 2012-06-13 02:00 pm (UTC)no subject
Date: 2012-06-13 06:58 pm (UTC)