DB2 SQL Scubbing Data в выписке с динамическими столбцами

Question

У нас есть AS400 с использованием DB2, и мне нужно скопировать данные клиента в новое место для анализа, но его нужно очистить, чтобы защитить конфиденциальную информацию. Я делаю это с 30-40 столами. ХП становится большим ...

Во всяком случае, для краткого примера, скажем, данные выглядят немного как это для колонн, а во 2-й строке, результат копируемых данных:

Col1 | Col2 | Name     | Sex | SS#  | Age | Col7 | Col8 | 
______________________________________________________________________________________________ 
* | * | Case when Sex = F, | * | 111111111 | * | * | * | 
      | then Jane Doe else | 
      | John Smith end  | 

Мои первая попытка это сделать массивную вставку, а затем обновить, что-то вроде:

Insert into New_Table (Select * from Old_Table) ; 
Update New_Table 
    set Name = (Case when Sex = ‘F’ then ‘Jane Doe’ else ‘John Smith’ End), 
     SS# = 111111111 ; 

проблема заключается в том, что на миллион строк, 200 столбцов и триггеры на таблицах, оператор вставки быстро, но обновление мучительно медленное - как в часах. Поэтому с помощью Stack я попробовал следующее:

Insert into New_Table (Select Col1, Col2, 
    (Case when Sex = ‘F’ then ‘Jane Doe’ else ‘John Smith’ End), 
    Sex, 111111111, Age, Col7, Col8) 

Работал как чемпион - спасибо команде Stack !!

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

Итак, я пытаюсь создать способ для создания инструкции SQL на лету и выполните его, чтобы столбцы были гибкими. Конечно, это добавит еще одну секунду к заявлению, чтобы построить его, но по сравнению с часами труда, когда происходит ошибка, это того стоит.

Я думал о том, чтобы использовать что-то вроде поиска в столбце, а затем подставлять только те столбцы, которые я хочу, создавая инструкцию SQL, а затем Exec для ее вызова. Я просто не могу придумать, как это сделать. Что касается построения инструкции, это может занять немного времени по сравнению с временем выполнения запросов. Например, я могу тянуть колонки с:

Select COLUMN_NAME from Sysibm.columns where tbname = 'old_table' AND table_schema = ‘MySchema’. 

Может быть, я могу положить, что в переменную, то поиск столбцов я знаю (имя, сс #) и заменить их, а затем построить заявление SQL и EXEC оно ? Результат оператора select для столбцов (см. Выше), хотя и не подходит для списка с разделителями-запятыми, как мне нужно. Насколько я могу судить.

Мысли кто-нибудь?

Спасибо, заранее.

Answer 1

Это:
Insert into New_Table (Select * from Old_Table)

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

Insert into 
New_Table (Col1, Col2, Name, Sex, SS#, Age, Col7, Col8) 
(Select Col1, Col2, 
    (Case when Sex = ‘F’ then ‘Jane Doe’ else ‘John Smith’ End), 
    Sex, 111111111, Age, Col7, Col8) 

Любые новые столбцы, добавленные в таблицу, должны иметь соответствующие значения по умолчанию. Теперь ваш процесс не будет прерываться при добавлении столбца.

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

Ваша идея использования syscolumns - хорошая, также есть List Fields (QUSLFLD) API. Вам придется создавать список с разделителями-запятыми по одному столбцу за раз в цикле.

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

wSQL = 'insert into new_table (' + wNonSrub + ',' + wSrub + ')' 
     + ' (select ' + wNonScub + ',' + wReplacement 
     + ' from old_table' + ')'; 

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

Answer 2

Ускорение вставок на AS400. У вас может быть много логических файлов, построенных над таблицей, в которую вы вставляете записи. Измените эти логические файлы REBLD (* DELAY)

CHGLF mylib/mylogicalfile rebld(*delay) 

Единственным побочным эффектом является первым человеком, и только первый человек, чтобы открыть файл в любой день, возможно, придется подождать несколько секунд, в то время как путь доступа перестраивается.