Я вижу две возможности: sqlite и BerkeleyDB. Поскольку мой вариант использования явно не реляционный, у меня возникает соблазн использовать BerkeleyDB, однако я действительно не знаю, как мне использовать его для хранения моих записей, поскольку он хранит только пары ключ/значение.
То, что вы описываете, - это именно то, о чем идет речь, даже если вам нужна только одна таблица. SQLite, вероятно, сделает это очень просто.
EDIT: реляционная модель не имеет ничего общего с отношениями между таблицами. Отношение — это подмножество декартова произведения других множеств. Например, декартово произведение действительных чисел, действительных чисел и действительных чисел (да, все три одинаковы) создают трехмерное координатное пространство, и вы можете определить отношение в этом пространстве с помощью формулы, скажем, x*y = z
. каждый возможный набор координат (x0,y0,z0)
либо находится в отношении, если они удовлетворяют заданной формуле, либо нет.
Реляционная база данных использует эту концепцию с несколькими дополнительными требованиями. Во-первых, и это наиболее важно, размер отношения должен быть конечным. Приведенное выше отношение произведения не удовлетворяет этому требованию, потому что существует бесконечно много троек, удовлетворяющих формуле. Есть ряд других соображений, которые больше связаны с тем, что практично или полезно на реальных компьютерах, решающих реальные задачи.
Лучший способ осмыслить проблему — подумать о том, где каждый тип механизма сохраняемости работает лучше, чем другой. Вы уже понимаете, что реляционное решение имеет смысл, когда у вас есть много отдельных наборов данных (таблиц), которые должны поддерживать отношения между ними (ограничения внешнего ключа), которые практически невозможно реализовать с помощью хранилища ключей и значений. Еще одно реальное преимущество реляционной модели — это то, как она делает возможными расширенные специальные запросы с использованием правильных индексов. Это является следствием того, что уровень базы данных действительно понимает данные, которые он представляет.
Хранилище ключей-значений имеет свой собственный набор преимуществ. Одним из наиболее важных является способ масштабирования хранилищ ключей и значений. То, что memcached, couchdb, hadoop используют хранилище ключей и значений, потому что это легко для распределения поиска по ключу-значению на нескольких серверах. Еще одна область, в которой хорошо работает хранилище «ключ-значение», — это когда ключ или значение непрозрачны, например, когда сохраненный элемент зашифрован, чтобы его мог прочитать только его владелец.
Чтобы понять, что реляционная база данных работает хорошо, даже если вам просто не нужно более одной таблицы, рассмотрите следующее (не оригинальное):
SELECT t1.actor1
FROM workswith AS t1,
workswith AS t2,
workswith AS t3,
workswith AS t4,
workswith AS t5,
workswith AS t6
WHERE t1.actor2 = t2.actor1 AND
t2.actor2 = t3.actor1 AND
t3.actor2 = t4.actor1 AND
t4.actor2 = t5.actor1 AND
t5.actor2 = t6.actor1 AND
t6.actor2 = "Kevin Bacon";
Что, очевидно, использует одну таблицу: workswith
для вычисления каждого актера с номером бекона 6.
person
SingleNegationElimination
schedule
08.11.2009