пятница, 18 июля 2014 г.

И еще "о сериализации" и "схеме данных". Теперь уже об "потоковой обработке"

http://programmingmindstream.blogspot.ru/2014/07/blog-post_16.html?showComment=1405713178230#c7653533082577736149

http://programmingmindstream.blogspot.ru/2014/07/blog-post_16.html?showComment=1405713588100#c5428060724828928348

Отмечу - я говорю не только про "копеечную" сериализацию, измеряющуюся сотнями килобайт или единицами мегабайт. Но и о данных которые измеряются десятками/сотнями, а то и тысячами мегабайт.

Чем ещё плоха "бинарная сериализация"? Или dfm-like использование TPersistent.

А тем что документ ПО-ЛЮБОМУ надо грузить в память и там уже обрабатывать.

Альтернатива?

Альтернатива есть - SAX-подобные техники.

Речь НЕ ИДЁТ ТОЛЬКО об xml, но xml и xlslt - это ХОРОШИЙ пример, на который СТОИТ смотреть.

Но не факт, что их СТОИТ напрямую использовать.

Но схема примерно такая:

Reader -> Filter1 -> Filter2 -> ... -> FilterN -> Writer

Фильтры принимают "поток данных" типа StartElement, FinishElement, StartRecord, FinishRecord, AddAtomicAttribute и принимают решения - что фильтровать, а что добавлять к этому "потоку данных".

При этом фильтры могут, что-то "буферизовывать", а что-то "обрабатывать на проходе".

Таким образом - фильтрам в общем случае НЕ НАДО "буферизовывать" ВЕСЬ документ в памяти.

Такое конечно - ТОЖЕ встречается. Если "для принятия решения" о трансформации данных "в НАЧАЛЕ документа" надо дождаться данные "находящиеся в его КОНЦЕ". Но это - ИСКЛЮЧИТЕЛЬНЫЕ случаи.

ОБЫЧНО - достаточно "буферизовывать", что-то "сильно локально".

Ну это я по своей более чем 20-тилетней практике "обработки документов" говорю.

Возможно у кого-то существует другая практика.

Ну и "вдогонку" - http://programmingmindstream.blogspot.ru/2014/07/blog-post_16.html?showComment=1405715420072#c7870653359150528237

И ещё мнение - http://programmingmindstream.blogspot.ru/2014/07/blog-post_16.html?showComment=1405716053630#c8590241723163075829

Комментариев нет:

Отправить комментарий