|
Верификация данных
|
|||
---|---|---|---|
#18+
Одна госорганизация передает данные другой. Передача данных из базы данных в базу данных производится посредством выгрузки/загрузки в/из xml-файл. Как проверить, что все что одна организация должна выгрузить - выгружается, а что вторая загрузить - загружается. (Вот блин завернул!). Т.е. как проверить, что данные в обеих базах корректны? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2006, 16:41 |
|
Верификация данных
|
|||
---|---|---|---|
#18+
Можно написать процедуру, которая подсчитывает контрольную сумму всех записей таблицы в БД-источнике и затем сравнивает с контрольной суммой в загруженной таблице в БД-приемнике. При этот формат хранения данных на физическом уровне должен быть идентичным в обеих БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2006, 17:19 |
|
Верификация данных
|
|||
---|---|---|---|
#18+
Тут еще проблема. Я не имею доступа к БД другой организации (откуда данные). Из таблиц выгружаются не все поля, т.е. таблица в xml-файле отличается от таблице в БД организации-выгрузщика данных. Таблицы xml по структуре и типу данных совпадают с таблицами в моей БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2006, 17:28 |
|
Верификация данных
|
|||
---|---|---|---|
#18+
gravТут еще проблема. Я не имею доступа к БД другой организации (откуда данные). Из таблиц выгружаются не все поля, Т. е. вы хотите сказать, что вам выгружают, например. таблицу "Штатное расписание', предоставляя все ее поля, кроме поля "Зарплата" ? И вы спрашиваете, как получить сведения о зарплате, не имея доступа к БД ? gravИз таблиц выгружаются не все поля, т.е. таблица в xml-файле отличается от таблице в БД организации-выгрузщика данных. Таблицы xml по структуре и типу данных совпадают с таблицами в моей БД. Такая ситуация может быть, например, в случае, если доступ к таблице контролируется расширенными средствами защиты (мандатный или дискреционный контроль). Например, в СУБД ЛИНТЕР лицо с грифом доступа "ДСП" пытается выгрузить таблицу, в которой есть некоторые данные с грифом "Секретно". В этом случае будут выгружены данные только с грифом "ДСП", секретные данные выгружены не будут, и не будет выдано никакой диагностической информации о том, что такие данные вообще есть в этой таблице. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2006, 19:57 |
|
Верификация данных
|
|||
---|---|---|---|
#18+
gravТ.е. как проверить, что данные в обеих базах корректны? А что Вы называете "корректны"? Можно проверить то, что в целевой базе оказалось то, что собирались отправить из исходной. Путь для этого указали - некий инвариант (контрольная сумма, for example), независимо рассчитываемый для выгружаемых и для загруженных данных. Если рассчитывать инвариант в ходе выгрузки - получим, что "данные не испорчены в пути", если рассчитывать выгружаемый инвариант независимо, перед выгрузкой - получим, что "выгружены все данные", "выгружены все данные для конторы Ч" итп - в зависимости от фильтров. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2006, 22:38 |
|
Верификация данных
|
|||
---|---|---|---|
#18+
Простейший способ, который используется у нас - выкладывание так называемых "футеров" - файлов с контрольными параметрами, в них указываестя какое количество строк, суммы ключевых полей, с группировками или без. С помощью таких файлов можно проверить валидность заливки . Также, при отсутствии таких файлов есть способ получить количество строк данных и сравнить с загруженным - часто этого достаточно. А валидность данных источника должна гарантироваться источником, но никак не приемником. Для этого у вас XML есть - это все-таки не текстовый файл, который может обраезаться в таком месте, что не будет заметно... Posted via ActualForum NNTP Server 1.3 ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2006, 11:36 |
|
Верификация данных
|
|||
---|---|---|---|
#18+
>ЮВ Нет, никаких дополнительных данных из базы-источника не требуется. Идет обычный обмен данными. Т.е. по закону одна госструктура обязана предоставлять сведения другой. Эта организация решила, что ей удобнее давать сведения в виде xml файла. Так и дают. Соответственно есть описание его структуры и типов данных. Данные эти поступают ко мне раз в месяц. Я в своей организации написал свою БД, которая разбирает xml и запихивает в базу. Недавно в базе были обнаружены ошибки. Соответственно встал вопрос на каком этапе они возникли. На этапе выгрузки в xml файл или на этапе загрузки в мою базу. Также встал вопрос об эквивалентности данных в базе-источнике и базе-приемнике. >softwarer Данные из своей базы мы предоставляем по запросам в другие госорганы. Корректные, имею ввиду правильные, как если бы они были из исходной базы. В пути данные не портятся, после выгрузки в xml файл расчитывается его контрольная сумма, перед загрузкой она проверяется. Если не совпадает, то не загружается. >Kull Damned В мою базу при очередной загрузке из файла xml попадают не все данные, т.к. если в базе-источнике какая то запись изменена, она будет выгружена в файл целиком (т.е. будут выгружены все строки таблиц относящихся к этой записи). В мою базу попадают только изменения. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2006, 13:16 |
|
Верификация данных
|
|||
---|---|---|---|
#18+
grav Я в своей организации написал свою БД, которая разбирает xml и запихивает в базу. Если вы пользуетесь не стандартными (входящим в состав СУБД) средствами выгрузки/загрузки, есть смысл проверить свои программы на предмет невыявленных ошибок. grav В мою базу при очередной загрузке из файла xml попадают не все данные, т.к. если в базе-источнике какая то запись изменена, она будет выгружена в файл целиком (т.е. будут выгружены все строки таблиц относящихся к этой записи). В мою базу попадают только изменения. Как выяснилось, вы не выгружаете таблицу целиком (на БД источнике) и не загружаете ее же целиком (на БД приемнике). Оказывается, вы выгружаете накопленные изменения (по какому критерию ?) и затем обновляете таблицу в БД приемнике. И возникает рассогласование данных. Надо анализировать параметры запроса на выгрузку, параметры запроса на обновление и полученный результат (дубликаты записей, отсутствие записей, непоследнее изменение полей и т. п.). Может, у вас дата и время в БД установлено разное ? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2006, 19:26 |
|
Верификация данных
|
|||
---|---|---|---|
#18+
ЮВ Как выяснилось, вы не выгружаете таблицу целиком (на БД источнике) и не загружаете ее же целиком (на БД приемнике). Так и есть. ЮВ Оказывается, вы выгружаете накопленные изменения (по какому критерию ?) и затем обновляете таблицу в БД приемнике.] Не совсем. Выгружаются измененные или вновь введенные в базу данные. Но целиком. Т.е. если поменялся хоть один символ в записи, выгружаются все данные отсносящиеся к этой записи изо всех таблиц, а не только изменение. Загружается же из xml файла только изменение. Критерий есть. Во первых данные в xml строго структурированы, структура в точности повторяет структуру БД со всеми ее связями. Во вторых для каждой записи в каждой таблице имеется дата начала ее действия и окончания. Видимо надо что то запросить из базы источника и сравнить с базой приемником. Но вот что именно в голову не приходит. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2006, 10:40 |
|
Верификация данных
|
|||
---|---|---|---|
#18+
> Видимо надо что то запросить из базы источника и сравнить с базой приемником. Но вот что именно в голову не приходит. Полный срез данных на последний момент выгрузки - и сравнить, либо поднимать старые файлы и первые бекапы и уже глядеть где глючокс вылез. У нас иногда появляются задания перезалить данные с самого начала, причем форматы могут меняться во времени - нужно поднимать историю изменений... В общем та еще работенка... Удач. Posted via ActualForum NNTP Server 1.3 ... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2006, 11:38 |
|
|
start [/forum/topic.php?fid=36&msg=33656601&tid=1555136]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
328ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
others: | 256ms |
total: | 679ms |
0 / 0 |