SQL vs версионность-иммутабельность
А вот что бывает когда реляционные БД ставят в несвойственную им позу и нет моральных ограничений (потому что кодогенерация):
кусок запроса "получить информацию об последних изменениях в БД, поддерживающей хранение всей истории изменений".
Ситуация вообще в следующем:
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 и переписывать все с нуля я не готов. За вопросами - к
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
2) N+1 запрос вообще и для Firebird в частности (сетевой протокол, лаги) - печаль. А то я бы всю сложность выкинул на клиента и там на F# собрал бы все что нужно. Впрочем, сервер и клиент (сервис-считалка) стоят рядом, ничего страшного, по идее, быть не должно.
3) В Firebird пока нет возможности сунуть код на произвольном языке в БД (как это есть у Postgres например)
PS: выяснил, чего сервер раком становится от таких запросов. Там дальше сортировка, не сводимая к чтению по индексам. Поэтому он начинает дичайше писать в временные файлы результат запроса и далее его читать. И файл размером 2 гига, внезапно, со скоростью 100 мег в секунду это таки 20 секунд на запись и потом хз сколько еще на фетч.
no subject
(no subject)
no subject
(no subject)
(no subject)
(no subject)
no subject
это большой страшный запрос чтоле?
(no subject)
(no subject)
(no subject)
no subject
А что такое "морально отказаться"?
(no subject)
no subject
(no subject)
(no subject)
(no subject)
no subject
PS Код в базе -- он у тебя будет "разъезжаться" с кодом в в гите (или чем тебе пауки велят пользоваться)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
(no subject)
(no subject)
no subject
сущноть, время_рождения_версии
надо хранить
сущноть, время_рождения_версии, время_смерти_версии
(no subject)
(no subject)
(no subject)
no subject
(no subject)