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

Тема в разделе "Lotus - Программирование", создана пользователем Akupaka, 29 июн 2010.

  1. Akupaka

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    Всем привет!

    Задумался тут на чем лучше, практичнее и работоспособнее организовывать импорт данных в Нотес-БД.
    Вот, к примеру, есть задача импорта данных из файла в формате 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.

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

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

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

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.073
    Симпатии:
    299
    это ты про что? ;)
    МСО файлы лочит - дык не юзай, тогда и остальной "огород" не понадобится
    или сделай сэйв-аз ХМЛ и закрой это подеделие :)
     
  3. Darker

    Darker Гость

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

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    Не лочит, на самом деле, а юзать надо, так исторически сложилось :)
    Если бы я знал! А может дело не в самом кол-ве, а в их использовании?..
     
  5. divankin

    divankin Senjor developer

    Регистрация:
    13 авг 2009
    Сообщения:
    182
    Симпатии:
    0
    По-моему, просто создаешь себе дополнительные проблемы. Какую цель преследуешь?
    Если хочется минимально лочить файл, то сделай его копию, с которой будешь работать монопольно сколько хочешь.
     
  6. nvyush

    nvyush Lotus team
    Lotus team

    Регистрация:
    22 апр 2009
    Сообщения:
    2.317
    Симпатии:
    0
    КМК, для файлов под 2Г сие не есть гуд.
     
  7. Akupaka

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    Человечество постоянно создает себе проблемы, так и были придуманы орудия труда, автомобили, самолеты ))
    Ой, надеюсь, таких фалов не будет )

    Вообще, я потому тут тему и создал, и не просто так писал: ))
     
  8. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.073
    Симпатии:
    299
    давай по-порядку - кто мешает?:
    -хранить хехель как ХМЛ (ёваный ОпенХМЛ) и парсеры к нему
    -использовать java либы для обсчения с сиим творчеством (они откроют на чтение, вряд ли залочат)

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

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

    divankin Senjor developer

    Регистрация:
    13 авг 2009
    Сообщения:
    182
    Симпатии:
    0
    А загружать файл весом 2Г в память есть гуд? А тем более создавать в памяти по объекту на каждую строчку?

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

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    Вероятно, мне только лень - я до сих пор не знаю явы ((
    В организационном плане, сейчас добавлять сохранение в xml будет лишь дополнительным действием, т.к. получать уже в xml не получится.
    А читать, что с екселя, что с xml мне одинаково "удобно".
    Работа с екселем, в принципе, есть временная замена некотороего функционала... надеюсь, что именно временным она и будет.

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

    divankin Senjor developer

    Регистрация:
    13 авг 2009
    Сообщения:
    182
    Симпатии:
    0
    Раз проблемы нет, значит, не стоит.
     
Загрузка...

Поделиться этой страницей