Мы рассмотрели основные алгоритмы, описывающие работу подсистемы управления параллельными заданиями в многоверсионной СУБД. Однако совсем не все рассмотренные алгоритмы активно применяются на практике. Какие же трудности встают на пути создателей многоверсионной СУБД?
Возникают проблемы здесь двух типов. Во-первых, требуется устроить физическую организацию данных так, чтобы можно было обеспечить эффективное управление версиями. Здесь следует учесть и разрастание объема базы данных при добавлении версий. То есть в идеале при организации данных должны учитываться возможные ограничения на количество версий. Заметим, что на практике ограничение на число версий зачастую отсутствует. Вместо этого система просто удаляет ненужные версии по мере завершения соответствующих транзакций.
Подобная ситуация наблюдается в СУБД MySQL. Речь идет о той конфигурации системы, при которой низкоуровневая работа с таблицами возлагается на подсистему InnoDB. В InnoDB используется одна из разновидностей протокола ROMV. Поскольку в этом протоколе все транзакции, вносящие изменения в базу данных, создают новые версии данных, то проблема ограничения числа версий стоит так же остро, как и в большинстве других версионных алгоритмов. В InnoDB удаление версий происходит в тот момент, когда они оказываются ненужными ни одной из активных транзакций. Таким образом, ответственность за поддержание умеренного количества версий ложится на пользователей СУБД. Они должен следить за тем, чтобы в системе не появлялись «длинные транзакции». В противном случае версии будут оставаться в базе данных, что приведет к нефункциональному увеличению ее объема.
Вторая проблема, возникающая при добавлении версий в архитектуру СУБД, имеет логический характер. Наличие версий должно приниматься во внимание во многих компонентах СУБД, помимо планировщика. В связи с этим, необходимо обеспечить корректное взаимодействие этих компнентов. Очевидным образом, с учетом версий должно происходить поддержание поисковых структур.