SQL vs версионность-иммутабельность

[metaclass]

А вот что бывает когда реляционные БД ставят в несвойственную им позу и нет моральных ограничений (потому что кодогенерация):

...
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 и переписывать все с нуля я не готов. За вопросами - к plumqqz, он вам расскажет, что думает за неосиливших СУБД.
2) N+1 запрос вообще и для Firebird в частности (сетевой протокол, лаги) - печаль. А то я бы всю сложность выкинул на клиента и там на F# собрал бы все что нужно. Впрочем, сервер и клиент (сервис-считалка) стоят рядом, ничего страшного, по идее, быть не должно.
3) В Firebird пока нет возможности сунуть код на произвольном языке в БД (как это есть у Postgres например)


PS: выяснил, чего сервер раком становится от таких запросов. Там дальше сортировка, не сводимая к чтению по индексам. Поэтому он начинает дичайше писать в временные файлы результат запроса и далее его читать. И файл размером 2 гига, внезапно, со скоростью 100 мег в секунду это таки 20 секунд на запись и потом хз сколько еще на фетч.

Comments

[metaclass.livejournal.com]

Не будет. В базу он попадает в самую последнюю очередь, со ссылкой на тикет и ревизию в vcs

[avnik.livejournal.com]

но вы зодб то пощупайте все равно.

[metaclass.livejournal.com]

Я лучше datomic пощупаю, или вообще berkeleydb и собственный фронтенд-запросы-оптимизатор

[nivanych.livejournal.com]

Может быть, лучше mongodb?
Она документно-ориентированная!
Вот спросите у plumqqz!
;-)

[metaclass.livejournal.com]

Я лучше у айседа спрошу, он ее кушает уже годами, и ругается на чем свет стоит.

[nivanych.livejournal.com]

На мой вкус, plumqqz выражается изящнее! ;-)

[nivanych.livejournal.com]

Правда, ради справедливости, надо сказать, что он-то её не использует.

[avnik.livejournal.com]

У монги кстати по моему те же родовые болезни что и у зодб (большой журнал и паковка базы).

[nivanych.livejournal.com]

Нунахрен. Пошутить могу, но всерьёз обсуждать ЭТО совершенно неохота :-)

[avnik.livejournal.com]

монгу или зодб?

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

[nivanych.livejournal.com]

zogdb я наблюдал с самого его начала.
И поначалу, даже был очень так воодушевлён. Но это продлилось недолго.

[avnik.livejournal.com]

У меня никогда не было такого объема, чтобы он начинал выглядеть говном. Ну и zodb+relstorage смотрится приятнее чем ORM (но опять же -- рассматриваем случаи когда внятной структуры данных нет)

[vp.livejournal.com]

Наваленность кучами блобов - это называется уже документоориентированность? :) А я думал просто свалка :)

[nivanych.livejournal.com]

Да! А ещё там есть распределённые транзакции!

[avnik.livejournal.com]

Что-то это datimic мутный, и денег стоит.