У меня уже давно сформировалось стойкое ощущение, что вы пытаетесь превратить простой парсинг в нечто суперсложное. Ваша новая идея это подтверждает.

Давайте набросаю вам прототипчик? У меня только один вопрос - одни и те же тэги на разных уровнях могут быть? Я спрашиваю только о тегах типа ‘Данные’, внутри которых есть другие, внутренности которых нужно собирать. Если эти тэги уникальны, то отслеживать уровни вообще не нужно. Если они могут таки повторяться на разных уровнях, тогда нужно делать так, как я написал.'

буду не против, т.к. не до конца понимаю Ваш код.
В файле содержаться сотни тегов <Данные>, сотни тегов <Отчеты> и такое же количество <Документов>.
в исходном xml в теги типа <Данные> всегда входят какие либо другие теги, их набор статичен для каждого из <Данных>, но отличается для <Отчетов> и <Документов> (для каждого из которых, в свою очередь они свои и также статичны). Теги, вложенные в теги типа <Данные>, также всегда наполнены определенным набором других тегов. Последние, в свою очередь, не обременены обязанностями быть наполненными и/или находиться там, но какое то их количество всегда там присутствует.

“Если эти тэги уникальны, то отслеживать уровни вообще не нужно. Если они могут таки повторяться на разных уровнях, тогда нужно делать так, как я написал”

Не могу сказать что не понимаю Вас, но все же не до конца.

Да, с пониманием у нас туго. Давайте на примере тэга ‘Данные’.
Вот такой xml:
<main>
<Данные>
<ДатаНачала>22.03.2011</ДатаНачала>
<Назначение>Торговля</Назначение>
<Комментарии/>
<ДатаОкончания>22.03.2011</ДатаОкончания>
</Данные>
<какой-то другой тэг>
<Данные>
<Что-то>содержимое чего-то</Что-то>
</Данные>
</какой-то другой тэг>
</main>
Реален? Или все-таки тэг ‘Данные’ всегда содержит тэги ‘ДатаНачала’, ‘Назначение’, ‘Комментарии’ и ‘ДатаОкончания’?
Может ли встречаться тэг ‘Данные’ на разных уровнях? Содержимое тегов внутри тэга ‘Данные’ складывается в одну и ту же таблицу в базу или в разные в зависимости от уровня, на котором находится тэг ‘Данные’?

Нарисуйте мне, пожалуйста, пример вашего многоуровневого xmlя с разными комбинациями тэгов и напишите какие тэги в какие таблицы и поля складывать. Я вам за это нарисую прототипчик, который будет его в один проход обрабатывать.

Вот вам мой прототипчик. Может с кодом будет проще. Я взял за основу простой вариант - интересующие нас тэги могут встречаться на любом уровне, но имеют одну и ту же структуру. Вместо собственно записи в базу я пишу в какую таблицу и в какие поля писать данные.
Вот xml:
Вот результат:
Пришло Данные
Пишем в таблицу ‘tab_data’
В поле target запишем Торговля
В поле end_date запишем 22.03.2011
В поле begin_date запишем 22.03.2011

Пришло Данные
Пишем в таблицу ‘tab_data’
В поле target запишем Обмен
В поле end_date запишем 24.05.2012
В поле begin_date запишем 23.04.2012

Пришло Документ
Пишем в таблицу ‘tab_doc’
В поле create_date запишем 04.11.2011
В поле name запишем Договор №07
В поле status запишем В доработке

Задавайте вопросы.

Ed
Вот такой xml:
<main>
<Данные>
<ДатаНачала>22.03.2011</ДатаНачала>
<Назначение>Торговля</Назначение>
<Комментарии/>
<ДатаОкончания>22.03.2011</ДатаОкончания>
</Данные>
<какой-то другой тэг>
<Данные>
<Что-то>содержимое чего-то</Что-то>
</Данные>
</какой-то другой тэг>
</main>
Реален? Или все-таки тэг ‘Данные’ всегда содержит тэги ‘ДатаНачала’, ‘Назначение’, ‘Комментарии’ и ‘ДатаОкончания’?

Нет. <Данные> может содержать определенный набор тегов, в каком то из тегов <Данные> могут быть все его теги, а в каком то только один из всего набора (это значит, что отсутствующие теги не содержат никакой информации, поэтому они отсутствуют)

Ed
Может ли встречаться тэг ‘Данные’ на разных уровнях?

Нет.

Ed
Содержимое тегов внутри тэга ‘Данные’ складывается в одну и ту же таблицу в базу или в разные в зависимости от уровня, на котором находится тэг ‘Данные’?

Вложенные в <Данные> теги идут в разные таблици одной базы в зависимости от вложенности.
Содержимое тегов “Данные” и “Отчеты”, а также “Документы” могут отправляться в разные таблицы, но в одну бд.

Ed
Нарисуйте мне, пожалуйста, пример вашего многоуровневого xml с разными комбинациями тэгов и напишите какие тэги в какие таблицы и поля складывать. Я вам за это нарисую прототипчик, который будет его в один проход обрабатывать.

XML:
<?xml version=“1.0” encoding=“windows-1251”?>
<main>
<Данные>
<ДатаНачала>22.03.2011</ДатаНачала>
<ДатаОкончания>22.03.2011</ДатаОкончания>
<Справочник.Номенклатура>
<IDD>11111110</IDD>
<Код>00000001</Код>
<Наименование>АКСЕССУАРЫ</Наименование>
<ПометкаУдаления>Ложь</ПометкаУдаления>
<ЭтоГруппа>Истина</ЭтоГруппа>
<Родитель>
<Вид>NULL</Вид>
</Родитель>
<СтранаПроисхождения>
<Вид>NULL</Вид>
</СтранаПроисхождения>
<НоменклатурнаяГруппа>
<Вид>NULL</Вид>
</НоменклатурнаяГруппа>
<Параметр1>
<Вид>NULL</Вид>
</Параметр1>
<Параметр2>
<Вид>NULL</Вид>
</Параметр2>
<Параметр3>
<Вид>NULL</Вид>
</Параметр3>
<Параметр4>
<Вид>NULL</Вид>
</Параметр4>
<Параметр5>
<Вид>NULL</Вид>
</Параметр5>
<Параметр6>
<Вид>Справочник._Параметры</Вид>
<IDD>1004811838</IDD>
<Наименование>Двойн</Наименование>
</Параметр6>
<Параметр7>
<Вид>NULL</Вид>
</Параметр7>
<Параметр8>
<Вид>NULL</Вид>
</Параметр8>
<Параметр9>
<Вид>NULL</Вид>
</Параметр9>
<Параметр10>
<Вид>NULL</Вид>
</Параметр10>
<Параметр11>
<Вид>NULL</Вид>
</Параметр11>
<Параметр12>
<Вид>NULL</Вид>
</Параметр12>
<Параметр13>
<Вид>NULL</Вид>
</Параметр13>
<Параметр14>
<Вид>NULL</Вид>
</Параметр14>
<НеВключатьВпрайс>Ложь</НеВключатьВпрайс>
<Услуга>Ложь</Услуга>
<Комментарий></Комментарий>
<НаименованиеПолное></НаименованиеПолное>
</Справочник.Номенклатура>
<Справочник.НоменклатурныеГруппы>
<IDD>10000002193</IDD>
<Код></Код>
<Наименование>АКСЕССУАРЫ</Наименование>
<ПометкаУдаления>Ложь</ПометкаУдаления>
<ЭтоГруппа>Ложь</ЭтоГруппа>
</Справочник.НоменклатурныеГруппы>
<Справочник._ОписанияПараметров>
<IDD>10000000562</IDD>
<Код>1</Код>
<Наименование>Модель</Наименование>
<ПометкаУдаления>Ложь</ПометкаУдаления>
<ЭтоГруппа>Ложь</ЭтоГруппа>
<Владелец>
<Вид>Справочник._ТипыТоваров</Вид>
<IDD>1000002193</IDD>
<Наименование>АКСЕССУАРЫ</Наименование>
</Владелец>
</Справочник._ОписанияПараметров>
<Справочник.Номенклатура>
<IDD>1000878340</IDD>
<Код>64842</Код>
<Наименование>Проставка с двойн</Наименование>
<ПометкаУдаления>Ложь</ПометкаУдаления>
<ЭтоГруппа>Ложь</ЭтоГруппа>
<Родитель>
<Вид>Справочник.Номенклатура</Вид>
<IDD>100485</IDD>
<Наименование>АДАПТЕРЫ</Наименование>
</Родитель>
<СтранаПроисхождения>
<Вид>NULL</Вид>
</СтранаПроисхождения>
<НоменклатурнаяГруппа>
<Вид>Справочник.НоменклатурныеГруппы</Вид>
<IDD>10048110000002193</IDD>
<Наименование>АКСЕССУАРЫ</Наименование>
</НоменклатурнаяГруппа>
<Параметр1>
<Вид>Справочник._Параметры</Вид>
<IDD>1004837</IDD>
<Наименование>Проставка</Наименование>
</Параметр1>
<Параметр2>
<Вид>NULL</Вид>
</Параметр2>
<Параметр3>
<Вид>NULL</Вид>
</Параметр3>
<Параметр4>
<Вид>NULL</Вид>
</Параметр4>
<Параметр5>
<Вид>NULL</Вид>
</Параметр5>
<Параметр6>
<Вид>Справочник._Параметры</Вид>
<IDD>1004881838</IDD>
<Наименование>Двойн</Наименование>
</Параметр6>
<Параметр7>
<Вид>NULL</Вид>
</Параметр7>
<Параметр8>
<Вид>NULL</Вид>
</Параметр8>
<Параметр9>
<Вид>NULL</Вид>
</Параметр9>
<Параметр10>
<Вид>NULL</Вид>
</Параметр10>
<Параметр11>
<Вид>NULL</Вид>
</Параметр11>
<Параметр12>
<Вид>NULL</Вид>
</Параметр12>
<Параметр13>
<Вид>NULL</Вид>
</Параметр13>
<Параметр14>
<Вид>NULL</Вид>
</Параметр14>
<НеВключатьВпрайс>Истина</НеВключатьВпрайс>
<Услуга>Ложь</Услуга>
<Комментарий></Комментарий>
<НаименованиеПолное>Проставка</НаименованиеПолное>
</Справочник.Номенклатура>
</Данные> # вне тега Данные, теги Справочник.Номенклатура и Справочник._ОписанияПараметров не существуют
<Остатки>
<Дата>22.03.2011</Дата>
<Строка>
<Номенклатура>
<Вид>Справочник.Номенклатура</Вид>
<IDD>80797</IDD>
<Наименование>hhhsdfhh</Наименование>
</Номенклатура>
<Количество>2</Количество>
</Строка>
<Строка>
<Номенклатура>
<Вид>Справочник.Номенклатура</Вид>
<IDD>3180797</IDD>
<Наименование>hhhhh</Наименование>
</Номенклатура>
<Количество>2</Количество>
</Строка>
</Остатки>
<Цены>
<Дата>22.03.2011</Дата>
<Строка>
<Номенклатура>
<Вид>Справочник.Номенклатура</Вид>
<IDD>10048110116803359</IDD>
<Наименование>01227 Возвратная пружина педали</Наименование>
</Номенклатура>
<ЦенаТ></ЦенаТ>
<ЦенаТ3>0</ЦенаТ3>
<ЦенаТ5>0</ЦенаТ5>
<ЦенаТ10>0</ЦенаТ10>
<ЦенаС></ЦенаС>
<ЦенаС3>0</ЦенаС3>
<ЦенаС5>0</ЦенаС5>
<ЦенаС10>0</ЦенаС10>
</Строка>
<Строка>
<Номенклатура>
<Вид>Справочник.Номенклатура</Вид>
<IDD>100481480849</IDD>
<Наименование>116 Гибкий нагреват.элемент к вулк-ру Комплекс1</Наименование>
</Номенклатура>
<ЦенаТ></ЦенаТ>
<ЦенаТ3>0</ЦенаТ3>
<ЦенаТ5>0</ЦенаТ5>
<ЦенаТ10>0</ЦенаТ10>
<ЦенаС></ЦенаС>
<ЦенаС3>0</ЦенаС3>
<ЦенаС5>0</ЦенаС5>
<ЦенаС10>0</ЦенаС10>
</Строка>
<Строка>
<Номенклатура>
<Вид>Справочник.Номенклатура</Вид>
<IDD>481154999</IDD>
<Наименование>215 Набор для ремонта покрышек л/а</Наименование>
</Номенклатура>
<ЦенаТ></ЦенаТ>
<ЦенаТ3>0</ЦенаТ3>
<ЦенаТ5>0</ЦенаТ5>
<ЦенаТ10>0</ЦенаТ10>
<ЦенаС></ЦенаС>
<ЦенаС3>0</ЦенаС3>
<ЦенаС5>0</ЦенаС5>
<ЦенаС10>0</ЦенаС10>
</Строка>
</Цены>
</main>


Это не весь файл, потому как в оригинале там около миллиона строк(700 - 800 тысяч), но в общем он состоит из перечисленных записей +- еще пара тегов внутри тега <Данные>
Тэги <Вид>,<IDD> и <Наименование>, как вы заметили могут находиться на разных уровнях, но в себе они никогда не несут еще уровни, только значения.
Кроме главных тегов (Справочник.Номенклатура, Справочник.НоменклатурныеГруппы, Справочник._ОписанияПараметров)
В <Справочник.Номенклатура> они могут входить в состав таких тегов как : Родитель,во все теги Параметр N, НоменклатурнаяГруппа, СтранаПроисхождения.
В <Справочник._ОписанияПараметров> : <Владелец>
А также <Цены>
<Строка>
<Номенклатура>
Вот сюда
</Номенклатура>
и <Остатки>
<Строка>
<Номенклатура>
Сюда
</Номенклатура>
Уточню, что БД достаточно далеко, поэтому хотелось бы данные сначала закидывать в переменные, а потом пересылать, что бы если происходил сбой, парсер смог отследить где произошел разрыв и продолжить с того места (но этот механизм мне еще предстоит прописать)
Запись в Таблицы соответственно называюся Spravochnik.Nomenclatura, Spravochnik.NomenclaturnieGruppi, Spravochnik._OpisParameters, Ceni, Ostatki.
Столбцы в Spravochnik.Nomenclatura: IDD, Cod, Naimenovanie, PometkaUdaleniya,Parents, CountryOrigin, NomenklaturnayaGruppa, Param 1 и до 14.
Столбцы в Spravochnik.NomenclaturnieGruppi: IDD, Cod, Naimenovanie, PometkaUdaleniya, EtoGruppa.
Столбцы в Spravochnik._OpisParameters: IDD, Cod, Naimenovanie, PometkaUdaleniya, EtoGruppa, Vladelec.
Прошу прощения, что Вам приходится так все разжевывать. В своё оправдание могу сказать только, что раньше не приходилось сталкиваться с ООП (разве что в университете на лекциях), ранее работа была связана только с низкоуровневыми, и все эти классы, потоки,и такое , на первый взгляд, беспорядочное пользование ими для меня в новинку, но благодаря Вам многое стало проясняться. Спасибо Вам за терпение и помощь.

На первый взгляд мое решение подходит. Не совсем понятно что делать с тэгами типа Parents, их же не сложишь в одно поле, поскольку они в себе содержат другие тэги.

Давайте так - вы попробуете использовать мой код с этим xml, а если что-то не будет получаться будете здесь спрашивать. Изменения поначалу будут касаться только входных данных, вот вам пример начала:
Забудьте про переменные. Для того, чтобы обеспечить сбор данных используйте словари, списки, то есть сложные структуры, а не простые переменные. Сбор данных нужно делать в классе DbWriter. Просто заведите там поле self.results и заполняйте его по мере прихода данных. А в конце все, что насобирали сбросите в базу. Это не принципиальное изменение.

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

Удачи.

СПАСИБО!!!!!! ОгромноЕ! Сейчас же засяду)
Определилось, что надо делать для <Параметр N>: для них (для каждого в отдельности) созданы таблицы с полями IDD (IDD присвоенный при создании записи внутри таблицы), IDDold (IDD с xml), Наименование, и в таблице Spravochnik.Nomenklatura идет поле Параметр N в каждой из которых указан IDDold для поиска нужной записи в таблице Параметр N.
Parents будет использоваться как указатель на родительскую таблицу (эту идею надо будет еще доработать)
Для НоменклатурнаяГруппа, также как и для Параметр N, будет создана отдельная таблица, и связь из Spravochnik.Nomenklatura с этой таблицей будет организована по полю IDDold.
Остальные вложенные пока обрабатывать не буду.

Вопрос: как в данном случае будет лучше организовать( для таких вложенных тегов как <Вид>, <IDD> и <Наименование> которые располагаются на последнем уровне вложенности) выгрузку в отдельные таблицы?
Создать отдельный класс для обработки всех Параметров и Номенклатурных групп, который будет отдельно их выдергивать и записывать в их таблицы? как рациональней?

Прошу прощения, что не отвечал долго - был в отъезде на выходных. Ну как, что-нибудь получилось?
Насчет IDD и прочего не совсем понятно. Приведите конкретный пример. В какие таблицы для каких тэгов чего писать. Попробуйте сделать сами, скажите что получилось, а что нет.
И вообще сделайте для начала чтобы работало для простого случая. Я пока не видел никаких результатов.

Здравствуйте. Касательно Параметров:
В Параметр N могут входить такие поля, как: Вид, IDD (ранее присвоенный другой программой) и Наименование.
Для каждого из Параметров будет создано по таблице, а также в таблице Nomenklatura будут поля Параметр 1, Параметр2, … , Параметр 14, которые будут связаны с соответствующей таблицей по средствам db.ReferenceProperty().

Результаты
from xml.sax.handler import ContentHandler
from xml import sax

class Handler(ContentHandler):
def __init__(self, fields, callback):
ContentHandler.__init__(self)
self.results = dict()
self.callback = callback
self.target = None
self.current = None
self.in_NomenGroup = False
self.in_Vladelec = False

def startElement(self, name, attrs):
self.current = name
if name in self.results:
self.target = name
if name == ‘НоменклатурнаяГруппа’:
self.in_NomenGroup = True
if name == ‘Владелец’:
self.in_Vladelec = True

def endElement(self, name):
self.current = None
if name in self.results:
self.callback(self.target, self.results)
self.results = {}
self.target = None

def characters(self, content):
if self.target:
self.results = content

class DBWriter():
def __init__(self, rules):
self.rules = rules

def write(self, name, data):
rules = self.rules
# print “Пришло”, name
# print “Пишем в таблицу ‘%s’” % rules
for key, fname in rules.iteritems():
print “В поле”, fname, “запишем”, data
print “”

if __name__ == ‘__main__’:

writer = DBWriter({u“Справочник.Номенклатура”: {“table”: “Nom”,
“fields”: {u“IDD”: “IDD”,
u“Наименование”: “name”,
u“Родитель”: “idB”,
u“Параметр1”: “param 1”,
u“Параметр2”: “param 2”,
u“Параметр3”: “param 3”,
u“Параметр4”: “param 4”,
u“Параметр5”: “param 5”,
u“Параметр6”: “param 6”,
u“Параметр7”: “param 7”,
u“Параметр8”: “param 8”,
u“Параметр9”: “param 9”,
u“Параметр10”: “param 10”,
u“Параметр11”: “param 11”,
u“Параметр12”: “param 12”,
u“Параметр13”: “param 13”,
u“Параметр14”: “param 14”}},
u“ОписанияПараметров”: {“table”: “OpParam”,
“fields”: {u“IDD”: “idc”,
u“Код”: “numpar”,
u“Наименование”: “name”,
u“”: “status”}}})
parser = sax.make_parser()
handler = Handler((u“Номенклатура”, u“ОписанияПараметров”), writer.write)
parser.setContentHandler(handler)
parser.parse(“for_web.xml”)
Определилось кол-во видов нодов для обработки. Набор нужных тегов, которые содержаться в них, и в итоге:
стало очевидно, что этот подход не для моего случая, т.к.:
1) Нужно обрабарывать содержимое 2-4 основных тегов (наподобие “Номенклатура” или “ОписанияПараметров”);
2)В парсере должен быть предусмотрен легкий разбор подуровней (почти,предел есть всему)бесконечного кол-ва уровней вложенности, потому как исходный документ может немного меняться в сторону увеличения уровней вложенности, поэтому надо предусмотреть легкое добавление обработчика последнего(возможно нового) уровня. Руководитель рекомендует (читай: настаивает) на варианте подхода с выдиранием по 1му ноду (типа “Номенклатура”) в переменную, и обрабатывать этот кусочек отдельно, преимущество: - позволяет легко изменять кол-во обрабатываемых уровней, а также нодов.

еще хотелось бы уточнить:
возможна ли запись куска файла (xml) в переменную или только освобожденной от тегов информации?
Если да, то каким путем стоит идти:
1) путь через работу с файлом как с файл-объектом, через open(filename) и т.п. (тут непонятно как он будет читать файл: каждый раз с самого начала?)
2) путь через многопотоковую организацию (но это, по-моему, край гемора переходящего в маразм)
3) не известный мне путь, выдирания из голого потока всего содежимого.
если нет, то как быть? можно, конечно, использовать Ваш метод записи данных, как именованных переменных, но тогда игнорируется условие, касательно большого количества уровней вложенности, о котором говорилось ранее (а соблюдение его очень важно).