Есть старая клипперная БД на 40 гб. Бухучет предприятия до 2007-ого года.
ПО к этой БД есть, но на вин-7 не запускается без dosbox, т.е. считаем, что его нет. Да и никто не помнит, как оно вообще работало.
Данные устарели, но раз в год кому-то может понадобится одна-две строки. Какие именно строки понадобятся в следующем году и понадобятся ли вообще, никто не знает.

В общем, приказали нам эти дбф-ки перегнать в Оракл. Пусть там лежат. Кому надо, и в Оракле найдёт.
Оракл 11.2.

100 тыщ дбф-ок.
Куча в основном похожих файлов – кредит, дебет, сальдо, журналы и прочая хрень каждого счета за каждый год.
Но сбивать все кредиты в одну таблицу не получится, т.к. файлы весьма похожие, но структура может отличаться.

Из этого НЕ НАДО делать реляционную БД.
Нужна гениальная идея:
- как всё это хранить
- чтобы место много не занимало
- легко искать произвольный текст. Например, как решали на днях: запустили ФАРом поиск по всем папкам и dbf-кам, искали ОКПО – код предприятия. Нашли несколько похожих таблиц, данные выгрузили в Эксель, пользователь остался доволен.

Варианты:
1. Сделать в отдельной схеме (нескольких схемах) 100 тыщ разных таблиц
Плюсы – проще всего – есть прога для заливки дбф в БД с созданием таблиц. Написать скрипт для заливки всех таблиц на основании результата dir - час времени. И 8 часов будет работать, пока не зальёт - и все затраты.
Минус – много таблиц получается и сложно искать в них произвольный текст.
Минус – ограничение на длину наименования таблицы. Полный путь не влезет в название таблицы.
2. Сделать EAV-таблицы. Основная таблица - Field_id, row_number, Value_строка, Value_Намбер, Value_дата.
Минусы: на каждое поле будет уходить много доп. места на Field_id и row_number.
3. Хранить каждую таблицу отдельной строкой в XML или JSON. Сделать общую таблицу из трех основных полей: Название таблицы с полным путём, CLob с данными, sql-запрос для получения данных. Полнотекстово проиндексировать.
Минус – куча места будет уходить под название атрибутов и прочую информацию.

miksoftА ежели в CSV?надо обдумать, идея нравится

у XML есть плюс - из него селект можно написать
для селекта из CSV придётся парсер писать?

кит северных морейсколько уникальных полей в 100к дбф-ок?еще не считал
а зачем?

miksoftandreymxдля селекта из CSV придётся парсер писать?А зачем, если andreymxданные выгрузили в Эксель, пользователь остался доволен.?
Раз в год можно данные кинуть в Excel или даже сконвертить в обычную таблицу, если нужно что-то сложное посчитать.хорошая идея, подумаю

SQL*PlusВсе файлы DBF положить на диск сервера БД.

Наделать из DBF'ов файлов CSV.

Написать скрипт/программу, который наделает 100 000 External Tables на 100 000 файлов CSV.

При редкой необходимости поиска чего-либо искать в файлах CSV/DBF обычным FAR'ом и/или SELECT'ом из External Tables.предложение miksoft мне больше по душе - с хранением csv в блобах