Есть задача:
Легкая база данных, предназначенная на данный момент для хранения документов произвольного формата, но должна быть потенциально расширяема для хранения произвольных данных.
Хранилище данных — скорее всего, out of process, поддерживающее транзакции, пригодное для одновременной работы нескольких клиентов (нескольких запросов). Возможно, для распределенной системы. ACID, короче говоря. Оптимизация в первую очередь под рендеринг документов, во вторую — под изменение. Для текстовых документов — под поиск... Но это я забегаю вперед. Необходимость стабильности приводит к необходимости работы с физической файловой системой. Объемы хранимых данных — до нескольких насыщенных документов размером до 2000-5000 страниц одновременно.

Документ получается путем импорта, экспорта набора форматов (XML, DOC, RTF, PDF, DWG, и их будет еще), конвертеры принимают на вход файлы и должны сохранять в эту БД и, соответственно, в обратную сторону для экпорта.

Проблема номер раз:
Выбор структуры документа. Для форматов типа PDF, DWG сама собой напрашивается иерархическая БД, не такая ограниченная, как в ARX, но для текстовых лучше поступить как MS с Word'ом, используя наборы "text range". Вопрос — возможно ли в одну упряжку впрячь осла и трепетную лань, или лучше сразу вести разработку в двух (больше?) разных направлениях?

Реализация хранилища данных. Для структурного хранилища желательно избежать накладных расходов типа обработки XML, так что формат — бинарный или ASN или что-придет-в-голову-еще... Для хранилища с "диапазонами текста" остро необходимо решить проблемы с рендерингом большей части документа при расчете позиции текста далеко от его начала.

Сравнительно большие объемы данных потребуют какой-то реализации системы подкачки?

Распределенность потребует какого-то языка запросов?

И, может быть, я упустил что-то еще?

Тема абсолютно новая для меня, поэтом жду помощи от знающих людей.