Импорт данных из внешнего источника, файла

Akupaka

А че я?.. О.о
04.10.2007
3 360
2
34
Kiev, Ukraine
#1
Всем привет!

Задумался тут на чем лучше, практичнее и работоспособнее организовывать импорт данных в Нотес-БД.
Вот, к примеру, есть задача импорта данных из файла в формате excel (формат не важно, но так попсовее выглядит).
Предположим, что каждая строчка из Н-столбцов соответствует одному документу в БД.
Как чаще всего поступает программист? Наверняка, читает строчку, преобразует ее в документ, читает следующую.
Во всяком случае, это самый простой и прямой путь. Так я и реализовал сейчас.
Вот появилась мысля, а не преобразовать ли этот процес таким образом: сначала читаем файл, записываем данные в буфер, отпускаем файл, преобразуем данные из буфера в документы.
Чего добились? Файл "занят" значительно меньшее время, представьте, что при создании каждого документа происходит заметная во времени проверка. Получили предполагаемое число импортируемых записей. Разделены операции чтения файла и преобразования записей в документы. Что-то еще, о чем я сейчас не думаю )
Минусы - реализация буфера.
Варианты реализации буфера: NotesStream, временные документы, свои объекты.

Буфер NotesStream:
ограничен как минимум 2 ГБ текста:
<!--QuoteBegin-Help+-->
<span class="vbquote">(Help)</span><!--QuoteEBegin-->bytes& = notesStream.WriteText( text$ , [ eol& ] )
text$ - String. The text to write, to a maximum of 2GB bytes.[/quote]
Встретил еще ограничение в 4 ГБ вообще: http://www-01.ibm.com/support/docview.wss?uid=swg21419401
Но, думаю, даже 2 ГБ это внушительная возможность для большинства задач импорта.
Надо писать какой-то парсер, либо юзать XML.

Буфер временные документы:
если их лепить в "рабочую" БД, то либо придется удалять, а потом стабы полезут куда ни попадя, либо красиво что-то делать. Писать во временную базу? Все-равно хужее чем в памяти.

Буфер свои объекты:
при большом кол-ве своих объектов в памяти нотес может покраснеть, всегда ли?

В общем, такая вот каша. Хотелось бы услышать практиков, ну и теоретиков тоже. А не борюсь ли я с мельницами, т.е. а надо ли? И, стандартный вопрос, кто как делает? :)
Спасибо за внимание.
 

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 438
351
homepage.mac.com
#2
Чего добились? Файл "занят" значительно меньшее время, представьте, что при создании каждого документа происходит заметная во времени проверка.
это ты про что? ;)
МСО файлы лочит - дык не юзай, тогда и остальной "огород" не понадобится
или сделай сэйв-аз ХМЛ и закрой это подеделие :)
 
D

Darker

Гость
#3
Буфер свои объекты:
при большом кол-ве своих объектов в памяти нотес может покраснеть, всегда ли?
Большое кол-во это сколько? у меня однажды 40k было, клиент не покраснел. Или этого мало для крушения фрегата?
 

Akupaka

А че я?.. О.о
04.10.2007
3 360
2
34
Kiev, Ukraine
#4

divankin

Senjor developer
13.08.2009
182
0
Москва
#5
По-моему, просто создаешь себе дополнительные проблемы. Какую цель преследуешь?
Если хочется минимально лочить файл, то сделай его копию, с которой будешь работать монопольно сколько хочешь.
 

Akupaka

А че я?.. О.о
04.10.2007
3 360
2
34
Kiev, Ukraine
#7
По-моему, просто создаешь себе дополнительные проблемы
Человечество постоянно создает себе проблемы, так и были придуманы орудия труда, автомобили, самолеты ))
для файлов под 2Г сие не есть гуд
Ой, надеюсь, таких фалов не будет )

Вообще, я потому тут тему и создал, и не просто так писал: ))
Хотелось бы услышать практиков, ну и теоретиков тоже. А не борюсь ли я с мельницами, т.е. а надо ли?
 

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 438
351
homepage.mac.com
#8
давай по-порядку - кто мешает?:
-хранить хехель как ХМЛ (ёваный ОпенХМЛ) и парсеры к нему
-использовать java либы для обсчения с сиим творчеством (они откроют на чтение, вряд ли залочат)

в отличии от встречающихся плохо-структурированых блоков ворда (хотя и с ними справляются парсеры), в хехель ХМЛ нормальный
и либы java могут работать с бинарниками хехеля
более того - работа через КОМу с МСО - медленная, сравнивая с текстом

я уже упоминал - когда писал рапер (т.е. подменял вызовы АПИ КОМы из LS, на свои классы) для замены работы с КОМ, для хехель - время обработки резко сократилось (в моём случае - более 7 минут экономии), правда я писал алгоритм "на запись" (т.е. создавался набор CSV и зиповался, вместо записи в хехель)
 

divankin

Senjor developer
13.08.2009
182
0
Москва
#9
КМК, для файлов под 2Г сие не есть гуд.
А загружать файл весом 2Г в память есть гуд? А тем более создавать в памяти по объекту на каждую строчку?

Человечество постоянно создает себе проблемы, так и были придуманы орудия труда, автомобили, самолеты ))

Ой, надеюсь, таких фалов не будет )

Вообще, я потому тут тему и создал, и не просто так писал: ))
Я если честно, так и не понял, какую проблему ты пытаешься решить с помощью такой загогулины. Уверен ли ты, что эта проблема действительно существует и действительно важна?
 

Akupaka

А че я?.. О.о
04.10.2007
3 360
2
34
Kiev, Ukraine
#10
Вероятно, мне только лень - я до сих пор не знаю явы ((
В организационном плане, сейчас добавлять сохранение в xml будет лишь дополнительным действием, т.к. получать уже в xml не получится.
А читать, что с екселя, что с xml мне одинаково "удобно".
Работа с екселем, в принципе, есть временная замена некотороего функционала... надеюсь, что именно временным она и будет.

Я если честно, так и не понял, какую проблему ты пытаешься решить с помощью такой загогулины
Проблемы как проблемы нет. Возникла идея разделить операции чтения данных из файла и обработки на отдельные подпроцессы.
Вот и спросил, а стоит ли она того, чтобы ее реализовывать вообще.