Всем доброго дня,

возникла задача импорта больших текстовых файлов с последующим разбором их содержимого по другим таблицам. Поскольку при импорте информация берётся из разных частей файлов и т.к. файлы очень большие возникла идея сначала зачитывать их во временные таблицы а потом уже разбирать и импортировать в целевые таблицы (разбирать их в памяти 32битного приложения просто нехватит памяти в 2 Гб). Поскольку после импорта эти данные не нужны хотелось бы эти временные таблицы потом удалять так что бы не оставлять в базе мусор.
Соотв. начал искать информацию по использованию временных таблиц в FB 2.5.9 и в перспективе в 3й версии.
Нашел что согласно документации при создании временных таблиц (мне по видимому нужно уровня соединения) надо использовать "GLOBAL TEMPORARY" и "COMMIT PRESERVE ROWS".
Далее возник вопрос - после того как таблица автоматически удаляется остаётся ли мусор в базе и до какого момента этот мусор будет существовать? Например будет ли он удаляться только при восстановлении из резервной копии или его можно собрать другим способом.
Хотелось бы ещё услышать что то о подводных камнях которые могут ждать при использовании временных таблиц с большим объёмом данных, на что стоит обратить внимание и где "подстелить соломки".
Где можно подробнее почитать о теме временных таблиц кроме документации (её сейчас активно штудирую на эту тему но информаци в ней не так много).

Спасибо за любые советы и информацию.

Дегтярев Евгений,

Datanorm

формат заточенный на обмена товарными артиклями, их группами, ценами на них и скидками.
Целиком зачитывать надо потому что всё в одном файле и понятно что зачитывать, становится только когда всё или проиндексировано или торчит в памяти (т.е. надо многократно позиционироваться в разные части файла). Предведущая версия софта что это делает (написанная ещё в 2005м) наткнулась на проблемы с памятью при импорте больших файлов в этом году. Начиная примерно от 10 млн строк софт вываливается примерно на 80% зачитывания данных с "Out of memory". Можно конечно вынести импорт в отдельное приложение и скомпилироватрь его как x64, но гарантии что файлы не будут расти дальше нет. Опять же, в приложении задействовано куча модулей используемых в основной 32х битной программе и все их вычленить и тоже перекомпилить под х64 проблематично.

не получится, не от нас зависит. Стандарт принят за основу кучей поставщиков и только в нём они присылают данные.

примерно так предведущий коллега и пробовал поступить. Использовал допиленный TbufferedFileStream в сочетании с индексами в памяти в которых и хранилась нужная информация для позиционирования в этом файле в последствии. И как раз этот индекс и вызывал переполнение в последствии. Т.к. Файлов может импортироваться за раз несколько, причём надо между ними прыгать итп. Там достаточно замороченная логика где неудобство формата сталкивается с логикой самого приложания. В эту часть мне ещё надо вникать самому. Сейчас надо определиться с архитектурой пока.

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

Могли бы Вы привести пример такой "понятности что зачитывать"?
И в чём проблемы с позиционированием в файле?

да, выше уже написал, что в память не лезет уже сам индекх позволяющий позиционироваться в этих файлах.
тут накладываеся ещё софт в котором это всё запускается, который тоже хорошо кушает память. Хорошое решение было бы просто выделить импорт в отдельное x64 приложене но это практически невозможно. Слишком много связей с другими х32 модулями а у тех с третьими. Софту уже больше 25 лет, для интерфейса одних только самописных фреймворков внутри использовано более трёх. Короче проще переписать нежели выделить и в х64 перекомпилить.