Загонять данные в структуру с хэш-таблицами vs (connect ":memory:") с клонированием.
Просто в задаче лишняя нагрузка на винчестер ни к чему.
Разворачиваю: делаю сервер, который будет использовать AJAX и отвечать на n запросов в секунду, формируя ответ на основе данных из sqlite-базы. Т.к. sqlite не может кэширование, это означает что n раз в секунду головке нужно долбать по бляшке винчестера, поэтому думаю над реализацией кэширования или создавать родную lisp'у структуру и загонять туда данные или использовать фичу sqlite с созданием базы в оперативной памяти (sqlite:connect ":memory") и просто копировать таблицы.
В такой постановке либо выкидывать sqlite из основного workflow и держать только в качестве редко обновляемого хранилища, либо цеплять более серьёзную базу. Судя по всему, нагрузка и масштабы применения пока небольшие, поэтому ИМХО надо рассуждать с позиций дальнейшего развития проекта (удобство сопровождения, масштабируемость и т.д.)
> цеплять более серьёзную базу.
Какую например? И чтобы было нетребовательно к процессорному времени винчестера.
На винтах схемка есть, конечно, но процессор это громко :) То есть за рамки одной машины выходить не планируется (раз уж сразу начали заморачиваться локальными ресурсами и оптимизацией)? Тогда выбираем тот вариант, который короче писать и минимально проверяем нагружением.
А можно немного поабстрактировать от особенностей реализации?
В какую сторону нужно проабстрагироваться я не понял, если честно :) Если это штука из соседнего топика, то всё держать в памяти, сливая раз в M минут на диск и не париться. Жалеть винты, когда у нас база в back end стоит, конечно, но не до такой степени. Обычно стараются минимизировать число обращений к базе на первых порах, а это вопрос алгоритмов в первую очередь.
Так вот вопрос в каком виде лучше это делать. Создавать свой велосипед или довериться sqlite?
Как писали классики "make it work, make it right, make it fast (в нашем случае disk-friendly)" Раз мы ожидаем копания с проблемой (в данном случае - ожидается необходимость экономии disk i/o), то при проектировании нужно а)уменьшить по возможности число обращений к базе (e.g. собирать в памяти не update на одну строку, а на 1000 и только потом дёргать) б) инкапсулировать работу потенциально проблемной части программы в отдельный модуль/кусок/угол/whatever, с которым работать через неизменный интерфейс. После того, как оно заработает, а потом ещё и заработает стабильно и правильно в щадящем режиме, оценить, действительно ли мы так жёстко убиваем диск, как ожидалось, и нас это всё ещё напрягает. Вот если тогда будет ответ "да", то в выделенном уголке, незаметно для остальной программы (а в лиспе так вобще на живом образе, если постараться) сначала попробуем выгрузку в память стандартную. Если не станет хватать памяти, то намутим свой велосипед (при подъёмной нагрузке и отсутствии других проблем). Если окажется, что проблем работы с данными немного больше, чем получается осилить, то тёмный уголок станет общаться с каким-нить PostgreSQL на отдельной телеге с RAID и т.д. и т.п., который помогут настроить серьёзные DBA с соответствующего форума.