Сохранение в поток (постановка)

Версия 19:12, 13 января 2007

Требования к новому сохранению в поток:

1. Увеличение скорости минимум в 10 раз;
2. Уменьшение размера файла минимум в 10 раз (при использовании двоичного формата);
3. Возможность сохранения в формате XML;
4. Не использовать бизнес-объекты;
5. Работать только с информацией о метаданных из реляционной БД. Сделать всю информацию, не укладывающуюся в реляционную схему, внешней по относительности к процессу сохранения (см. например, аттрибут "Перезаписывать данными из потока").

Увеличение скорости

Беглый анализ показывает, что основной проблемой существующего сохранения является использование рекурсии и бизнес объектов. Сейчас работает так:

1. начинаем сохранять запись определенного типа (запись бизнес-объекта);
2. создаем клиент датасет и переносим в него данные полей сохраняемой записи;
3. записываем в поток служебную информацию и данные клиент датасета;
4. находим поля-ссылки, создаем экземпляры бизнес-объектов соответствующего типа и рекурсивно вызываем процедуру сохранения в поток, т.е. переходим к п. 1;

таким образом, в процессе сохранения объект одного и того же типа может создаваться неограниченное число раз.

Итак, первый шаг -- мы отказываемся от рекурсии. А это значит, что мы будем повторно использовать объект одного типа, если ранее уже такой встречался. Точнее, рекурсия все же будет, но при сохранении объекта определенного типа, от которого зависит сохраняемый в данный момент времени объект, мы будем попадать (рекурсивно) в его же код! Следует быть осторожным и контролировать повторное использование ресурсов.

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

Отказавшись от бизнес объектов приходится брать на себя анализ структуры базы данных и по главной таблице бизнес объекта (GetListTable) находить все таблицы связанные связью один-к-одному, а так же таблицы элементов множества. Тут возникает интересный момент: у нас, главная таблица для любого документа -- это gd_document, хотя специфические его данные хранятся в присоединенной таблице. При анализе связей таблицы gd_document находим 216 ссылающихся таблиц. Пока не ясно, стоит ли с этим смириться или каким-то образом отсекать таблицы, связанные с gd_document, но не имеющие отношения к типу сохраняемого бизнес-объекта.

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

1. какие таблицы имеют отношение один к одному к главной таблице;
2. какие таблицы имеют ссылку на главную таблицу с доменом MASTERKEY;
3. какие таблицы входят в SELECT-запрос бизнес-объекта;

Имеет смысл производить эти вычисления один раз для каждого класса + сабтайп.

Уменьшение размера файла

Уменьшения размера файла мы добьемся за счет отказа от рекурсии при формировании потока данных из-за которой мы имеем следующую внутреннюю структуру файла:

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