K C++ вопрос не относится, вообще-то. Это ближе к проектированию систем и администрированию баз данных.

В общем случае миграция делается так:
- Читаешь строку из исходной таблицы.
- Проверяешь на правильность данных.
- Если нашел кривые данные - пытаешься догадаться что оператор имел в виду когда печатал чушь. Например если ты знаешь что работаешь с датой рождения и видишь человека родившегося в 2070-ом году - догадываешься что это должен быть 1970 и исправляешь.
- Если исправить не получается - либо обнуляешь кривые данные, либо сбрасываешь в какое-то специальное значение, либо убиваешь строку (или весь логический объект) целиком.
- Не забывай записывать все случаи исправлений-убиваний записывать в журнал. Потом читай его и ищи где можно улучшить процедуру исправления кривых данных. После нескольких прогонов получишь конфетку.

И все...

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

MasterZivЗагрузка в БД во временное хранилище оправдано только, если другими способами как в БД (используя естественно SQL или PL SQL)
данные не обработать. А так -- это напрасная трата времени и ресурсов.Не знаю при каких условиях данные нельзя почистить на клиенте.
Вот как раз временные хранилища в БД я назову напрасной тратой времени и ресурсов.

sherzod_,
Замечание о потоках верно, все остальное не верно.
Ни блочные заливки, ни "штатные средства" ему не помогут. Первое умрет на этапе кривых данных (прочитай первый пост топика). А "штатные средства" либо тоже умрут на кривых данных, либо потребуют не малых денег, а потом еще и не малого времени на настройку.

denis_stell,
Мне сильно кажется что ты занимаешься переливкой данных. Читаешь из одной таблицы и пишешь в другую. Так? Если "да", то очень плохо.
Сделай на клиенте структуры (классы) представляющие собой бизнес-объекты. Потом заполняешь эти объекты из одной базы, и после того как собрал объект целиком - пишешь в новую базу. Простой цикл в один поток. Просто, легко и надежно.
Этот подход даст тебе намного более удобный для дальнейшей работы лог ошибок. Сможешь писать туда что-нибудь в духе: "Клиент ФЫВА имеет плохую дату в дне рождения. Клиент ЯЧСМ имеет три контракта в списке контрактов, но найдено только два контракта найдено в реальности". Потом отдаешь этот список начальству и тем кто вбивает данные в старую базу - они исправляют данные.
Заодно сможешь с легкостью изменить структуру хранения данных в новой БД.
У меня подобные схемы работали (и работают) очень даже замечательно.
А по скорости работы зависит от объема исходной базы и драйверов доступа к базам. Когда-то, на заре века, у меня двухгиговая DBF база превращалась таким образом в ASA7 за два часа. Сегодня 50Г данных переливаются из MS SQL 2008 в ASE 15 за час. В обоих случаях программы-превращатели написаны на С.

sherzod_White Owl,

о чем это вы. Это стандартная ДБА задача. Какие еще программы на компилируемых языках. Люди на TransactSQL биллинги целые пишут, включая работу с устройствами, файлами и со всем остальным, а вы говорите на плохих данных ляжет ).Это далеко не стандартная задача и уж совсем не для DBA. Это задача для дата-архитектора, а не администратора сервера.

sherzod_ Ровно один запрос на каждую таблицу, независимо от того что там с данными, ровно два запроса при использовании bulk insert.Вот это и есть твоя ошибка. Ты не смотришь на то "что там с данными". Да, в идеальном мире, источником данных будет идеальная база с идеальной целостностью данных. Тогда действительно данные типа "имя" или данные типа "адрес" можно получить разом по всем контрагентам за один запрос. Но в реальности, мы вынуждены жить с базами в которых бывают контрагенты без имени и имена без контрагентов.
А так же, задача миграции с одной базы на другую всегда сопровождается сменой структуры базы. Раньше имя хранилось так, а теперь имя будет хранится сяк. Раньше накладные хранились в двух таблицах, а сейчас будут в двадцати-двух. Смену структуры хранения ты в конечно в несколько запросов упихать сможешь, но bulk insert обломается.

sherzod_ При том что править их в десятки раз быстрее, поправил-попробовал, поправил-попробовал. А тут компилируй, подключись, запусти, посмотри, ищи ошибку. Смех да и только.Смейся. Когда сам попробуешь позаниматься мигрированием БД - будешь смеяться еще раз.

sherzod_White Owl,

Вы понимаете что TransactSQL может все? В том числе обработать любые ошибки в данных. Это полноценный язык программирования предназначенный именно для таких задач. Но даже это не важно. Важно то что в даже рамках ANSI SQL указанная задача преобразования дат решается простым coalesce.То что задачу решить можно этими средствами, не означает что ее нужно решать этими средствами.
Я разве когда-то говорил что миграцию невозможно сделать на чистом SQL? (кстати, TransactSQL очень хиленький диалект). Я говорю об эффективности и скорости решения задачи.


sherzod_А миграцией данных тут каждый первый занимался. На скульру как никак находимся. И уж точно никакой DB специалист не станет писать для миграции программу на си или плюсах. Это нонсенс.Ну я писал. И пишу.
При этом и "штатные средства" (в частности Data Services от BO) тоже используются, так же есть несколько баз таскающие данные друг у друга через linked/proxy tables. А одна связка сделана на bat+bcp и ниче, живет и здравствует.
Вот только почему-то мои клиенты на С обрабатывают больше данных и делают это быстрее. И логи от них можно впрямую отдавать секретарям-машинисткам для исправления ошибок в исходных базах (секретари-машинистки ничего не знают о структурах этих баз и часто вообще не знают что такое база данных).

sherzod_У нас для таких задач максимум что написано (причем на шарпе), так это скриптовалка, которая анализируя схему выдает скрипты дифов схем. А вы говорите миграция на плюсах. Не 80-й год ведь. Пока вы там неделю ваять будете и баги править, DBA вам скриптик накатает минут за 5 для одной таблицы, со всеми обработками ошибок. Да пожалуйста, пожалуйста. Хочешь спихнуть задачу на DBA и заставить его катать скриптики - вперед. Только учти что это ты не решаешь задачу на самом деле, а ты спихиваешь задачу на кого-то еще и надеешься что она будет решена эффективнее чем ты сам ее решишь. Только и всего.
Не хочешь мне верить что клиент построенный вокруг бизнес-объектов эффективнее и удобнее чем блочная обработка таблиц - не верь. ССЗБ, как говориться...

sherzod_Еще на фортране посоветуйте миграцию сделать. Фокус пойдет? У нас одна из связок именно на нем работает. С мейнфрейма данные выкачиваются Фокусом в файлы, потом программка на Rexx сортирует их и пересылает по ftp на AIX'овый хост, а там их подхватывают несколько сотен Perl'овых скриптов которые уже и заливают данные в ASE. И если перловую половину миграции можно переписать на что-то еще, то фокусную - обломинго, ограничения платформы.
И все это отрабатывает каждую ночь...

sherzod_И не путайте роли. Дело архитектора схему разработать а не скриптики миграции писать, последнее теоретически делает дба или разработчик, а практически дба или дба.ню-ню :)

denis_stellинтересен ваш вариант, можете привести пример(код), на пальцах или ссылку где есть что-то подобное?
А это чем не на пальцах?
White OwlСделай на клиенте структуры (классы) представляющие собой бизнес-объекты. Потом заполняешь эти объекты из одной базы, и после того как собрал объект целиком - пишешь в новую базу.

sherzod_Другое дело, что наиболее вероятный путь который он пройдет (мой друг) - начнет понимать что тексты запросов надо выносить из кода, потом начнет понимать что надо как-то их шаблонизировать (слишком много схожестей), будет добавлять расширенную параметризацию запросов, потом начнет делать конструктор, начнет более-менее понимать что в диалекте его базы довольно много полезных функций, добавит скриптовалку на Lua или JS, и в конце концов придумает свой SQL PL, увидит что он только что заново написал жалкую пародию на диалект используемой базы, и будет просветлен, разве вам это не знакомо? А если не пройдет, значит сила привычки оказалась сильнее.

While Owl, и не говорите что у вас в утилитах не присутствует ничего из выше-описанного :)).В утилитах миграции - нет, не присутствует. Ты забываешь что время жизни у таких утилит ограничено.
Самый долгий период что я видел - два года. Контора не торопясь переходила с системы учета клиентов на Клиппере на новую систему на PowerBuilder. С год эта новая система писалась и отлаживалась на основе фиктивных данных, потом мы решили что пора уже тестировать на более приближенных к реальности данных и я написал соответствующий конвертор. Два года он еженочно конвертировал данные всех филиалов из DBF в офисную базу на ASA7. Потом распространялся в составе инсталлятора новой системы. Отработал по разу во всех филиалах и франчайзах и ... умер.
Сейчас уже с полгода подобная система крутится (и по тем же причинам) в одной из наших школ. Там переходят с MS SQL 2008, на ASE 15.5. Можно конечно было и связанными таблицами сделать, но количество кода на TSQL получалось таким же как и количество кода у клиента на С. Смена структуры хранения данных очень не способствует краткости кода, знаете ли. А по скорости клиент получился быстрее. Да и логи объекто-зависимые это огромный плюс. Но очень скоро новый ГУИ будет готов и этот конвертор тоже умрет...
Что ты там шаблонизировать собираешься я не очень представляю. У старой базы структура не меняется в принципе, а с новой работаешь чистыми insert'ами и update'ами. Причем знаешь что завтра возможно эти insert'ы и update'ы придется подправить. И никакой метаинформации у развивающейся базы нет. А если и есть, то она частенько отстает от реальной структуры.

А свои скриптовалки и расширения SQL я изобретал. Как же без этого! :) Но это было (и есть) на задачах близких к отчетным системам. Вот там шаблоны и скриптовалки делать есть смысл.
А PL/SQL мне тоже не нравится. Вообще, мне сильно кажется, что чем древнее диалект, тем более он неудобный. Почему-то разработчики СУБД сделав более-менее приемлемую реализацию SQL замирают и перестают улучшать свой диалект. Потом приходит новый игрок, делает более лучший диалект и постепенно тоже замирает....