Hello, Alexey!
Alexey Popov wrote:
Можно, можно извернуться и наигать интернационал ложками. Но задача в
общем случае широко растространённая. Когда большой поток данных идёт.
Тут два решения: либо не удалять вовсе, либо удалять. Задач таких много:
билинг, датчики и т.п. Это мы знаем что есть такие грабли, но новички
всегда будут наступать на них.
в данном случае - именно интернационал ложками. Биллинги и датчики
делаются и без нашего этого обсуждения, кстати.
А вот в данном случае - не покатило. Не принижая достоинств FB
и версионного движка вообще, заявляю, что для прямого решения задач
биллинга, или вернее, "прокачивания" временной информации через базу,
вресионный движок НЕ ПОДХОДИТ.
У него другие задачи. Которые он успешно решает. И которые не решает
например безтранзакционный MySQL, DBF, и иже с ними.
Если бы одной архитектурой можно было бы решить ВСЕ задачи,
то она бы и была ОДНА. А так - их несколько.
Например, почему MS SQL, введя версионность в версии 2005,
тем не менее не убрал блокировочную архитектуру?
Почему у PostgreSQL до недавних пор мусор можно было собирать
только в монопольном режиме?
Есть-ли вообще в версионных движках механизм "массового удаления
без версионности", и как он реализован?
Похожих вопросов можно накидать еще много.
Пока (!) ситуация следующая:
1. автор вопроса сумел по крайней мере временно преодолеть
проблемы с производительностью, при помощи "коллективного разума".
2. автор вопроса, тем не менее, планирует уйти с ФБ в перспективе,
и я его в этом понимаю. Там где появляется 1 гиг за интервал времени,
может скоро стать и 2 и 10.
И, исходя из пункта 2, и вышеизложенного, я не вижу глобальной
проблемы, по которой надо версионный движок комбинировать с
блокировочным. Идеи "безверсионных" таблиц для IB/FB, по-моему
витают уже много лет (~10?). Но, если у MS SQL без версионности
все было хорошо, зачем он ее внедрил??? Очевидно, решать
задачи того типа, которые на блокировочнике работают хуже, чем
на версионнике. Я неправ?
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
