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 замирают и перестают улучшать свой диалект. Потом приходит новый игрок, делает более лучший диалект и постепенно тоже замирает....