и наконец третий способ* - использовать промежуточную С-программу, а то и просто awk-cKpum. Этот скрипт обрабатывает текстовый файл, полученный от мэйнфрейма, преобразовывает код статуса заказа и делит цену на количество, чтобы полученный в результате текстовый файл можно было обработать средствами SQL*Loader.

Эти решения сложнее, так как требуют наличия ЗСЬ-программы (или, по крайней мере, awA:-скрипта), но гораздо эффективнее и надежнее. Их использование дает несколько преимуществ:

В базе данных вьшолняются только действительно необходимые операции (например, операция вставки в две таблицы).

Размер сегмента отката и время восстановления поддаются контролю. (Для перезапуска экземпляра в случае неконтролируемого останова в ходе описанного выше процесса с использованием SQL*Plus может потребоваться несколько часов.)

Не выполняется фиксация для неполных заказов.

Существует тенденция к тому, что строки, относящиеся к одному заказу, будут располагаться рядом.

Особенностью двух последних методов является использование 3GL-средства как для преобразования кодов, так и для корректировки значений полей. Многие проектировщики пытаются сэкономить время и деньги, выполняя корректировку значений с помощью скрипта на SQL*PIus после загрузки, и во многих случаях еще более усложняют проблему, используя справочную таблицу, например:

INSERT INTO orders { order no , cust no , order status

SELECT w.order no , w.cust no , o.new code

FROM work table w

, order status codes о WHERE o.old code = w.order status;

Если в условии используется только одно соединение, этот код будет работать достаточно хорошо, однако при вводе еще двух-трех соединений производительность заметно ухудшится.

Если нельзя считать хорошим стилем жесткое программирование преобразования кодов в ЗОЕ-программе, то соединение вообще очень просто сделать управляемым данными. Перед чтением файла ЗОЕ-программа

Это одно из многих ценных дополнений и исправлений, сделанных Грэмом Вудом в процессе рецензирования этой книги.

прочтет таблицу ORDER STATUS CODES в память (в виде массива или связного списка) и будет выполнять замену кодов, используя собственный механизм табличного поиска. Эта программа также может сообщить о записях с недопустимыми кодами, В SQL-решении все строки заказов, чей ORDER STATUS в таблице ORDER STATUS CODES отсутствует, будут попросту проигнорированы. А это, конечно, совсем не то, что нужно.

Большинство этих недостатков решения на базе SQL*P]us можно избежать путем использования PL/SQL. Преимущество этого подхода в том, что данные все равно загружаются в рабочую таблицу, но вместо 21 прохода по ней делается один проход в курсорном цикле PL/SQL с выполнением всех необходимых операций. С точки зрения программирования и тестирования, этот метод гораздо дешевле ЗОЕ-профаммы. Он позволяет управлять интервалом между фиксациями, избежать фиксации противоречивых данных и разместить рядом строки одного заказа (как ЗОЬ-метод). Это - хорошие новости. Плохая новость заключается в том, что цикл в PL/SQL выполняется очень медленно. Если речь идет менее чем о 100000 строк, то можно бросить на решение этой проблемы дополнительные силы и время, но если необходимо принять больший объем данных за короткое время, то курсорные циклы PL/SQL попросту не справятся с возложенными на них задачами.

Форматы файлов

Двумерные (плоские) файлы, используемые для загрузки данных, могут иметь два формата: с записями фиксированной длины или с записями переменной длины. В записях переменной длины поля отделяются ограничителями. Примеры данных в формате фиксированной и переменной длины приведены в примере 8.1.

Пример 8.1. Записи фиксированной и переменной длины

Записи фиксированной длины

Widdington Tommy 11-11-72 164 04-26-90 У Magilton James 01-24-68 195 02-19-23 N

Hopper Neil 05- 4-70 180 12-06-91 У

Записи переменной длины

Widdington , Tommy , 11-11-72 , 164 , 04-26-90 , Y Magilton , James , О 1-24-68 , 195 , 02-19-23 , N Hopper , Neil , 05-4-70 , 180 , 12-0 6-91 , Y

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

Затем в примере приведены те же данные в переменном формате. Длина записи зависит от длины полей. Каждое поле заключается в ограничители (в

двойные кавычки) и отделяется от других полей специальным разделителем (запятой). Если символ ограничителя может использоваться и в тексте данных, необходимо указать программе-загрузчику, чтобы в тексте она интерпретировала этот символ буквально. Например, если нужно загрузить значение Nicholas Nic Banger, то следует использовать что-нибудь вроде Nicholas \ Nic\ Banger, где \ - управляющий символ, предписывающий программе рассматривать следующий символ буквально. Конечно, нужно сделать так, чтобы программа загрузки данных понимала эти обозначения.

Пустые значения в записях фиксированной длины обычно представлены пробелами, а в записях переменной длины - парой ограничителей ( в данном примере).

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

-- Это комментарий

SQL*Loader поддерживает комментарии этого типа.

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

Еще одной проблемой является обработка данных со встроенными символами новой строки. Вот нащи любимые методы ее рещения (в порядке предпочтения):

не иметь в строковых данных встроенных символов новой строки;

использовать обозначение Unix - \п, а встроенные знаки табуляции записывать как \t.

Столкнувшись с какой-либо из вышеупомянутых проблем, вы можете прийти к выводу, что лучще выполнять загрузку с помощью ЗСЕ-программы или, по крайней мере, использовать ЗСЕ-программу для предварительной обработки загружаемого файла с тем, чтобы его могла обработать программа SQL*Loader.