Есть ли что-нибудь между хранилищами значений ключей и полными базами данных SQL?

Question

Я часто сталкиваюсь с проблемой, что у меня есть массивы простых (POD) объектов, и мне нужно сохранить их на диск, найти содержимое по одному столбцу и извлечь его.

Давайте возьмем в качестве примера простой кэш:

id: Integer
expires: Date
query: String
result: String

Обычные операции - сохранение объекта (# 1), извлечение объекта по идентификатору (# 2) и удаление всего после определенногоdate (# 3), без использования DSL, который должен быть проанализирован во время выполнения (# 4).
Поскольку я знаю формат моих данных, мне не нужна поддержка для хранения произвольных документов (# 5).

Это должно быть достаточно распространенным, чтобы привести к потоку библиотек, делающих именно это, но я вижу только хранилища ключей-значений, такие как bdb, tokyocabinet и т. Д. (Которые не работают из-за #3) полнофункциональные базы данных SQL, включая SQLite, MySQL и т. Д. (# 4), а также базы данных без схем, такие как CouchDB, MongoDB и т. Д. (# 5).Сохранение его в виде простого CSV / XML / JSON работает достаточно хорошо, но плохо работает с № 2 и № 3.

Я ищу что-то вроде Мульти-индекс Boost (ноиспользование диска в качестве хранилища) или Squeryl , но с использованием собственного бэкэнда вместо прославленного компилятора DSL-to-SQL.
Есть что-нибудь подобное, или я чертовски разбираю CSV вручную илинаписать огромное количество шаблонов, чтобы использовать преимущества базы данных SQL?

Answer 1

MongoDB (и, возможно, другие базы данных noSQL) позволяют иметь более одного индекса в таблице.Но даже с системами типа ключ / значение ничто не остановит вас , создающего вторую таблицу, использующую дату в качестве ключа и ссылающуюся на ключ из таблицы данных в качестве полезной нагрузки и использующую его в качестве индекса.

Однако, если у вас нет особых причин для использования нереляционной базы данных, я бы порекомендовал придерживаться реляционной базы данных - рано или поздно вам придется начать отлаживать ваши данные / анализировать шаблоны, обрабатывая более сложныемодели данных и т. д.

Answer 2

Звучит как то, что обычно делается в обычной базе данных SQL. Если вы создаете хороший фабричный метод для сохранения и загрузки этих объектов, каждая из этих фабрик (если вы получили более одного типа объекта) должна реализовать только два запроса (сохранить и загрузить) и, возможно, третий для обновления. Если ваши объекты отображаются непосредственно в записи таблицы, вы даже можете создать базовый объект, который просто сопоставит свойства с именами полей и сгенерирует эти запросы для вас. Поскольку почти на каждом языке есть библиотеки почти для каждой базы данных, вы можете настроить это в течение дня, даже если вы не используете одну из многих функций DBO, которые поддерживают многие языки. Простая реализация, вероятно, займет менее 200 строк кода и, вероятно, уже более мощна, чем то, что вы делаете сейчас с CSV.