Oracle and Nexus

По Oracle, насколько я понимаю, речь идет не о миграции, а о наличии рядом новой
БД под MSSQL с периодической синхронизацией.

Я бы не стал выбирать путь синхронизации так как этот путь постоянной головной боли, особенно в распеределенных системах, где достаточно одного сбоя канала, чтобы объяснять, что вновь сделанное не причина выхода из строя the production informational system.

Изюминка состоит в том, что старый и новый клиент работают параллельно на одной и той же БД. Тогда (в начале) недоделанное в новом интерфейсе восполняется в старом, до тех пор, пока не достигнута полная функциональность нового. тем самым мы достигаем безболезненного замещения нового старым и не тратим силы на синхронизацию, репликацию и прочие проблемы. Такой путь приводит к 100% успеху.

Локализация клиента Nexus также необходима. Это еще один плюс к написанию нового клиента, где все разводится ресурсами.

Forums: 

предлагаю испробовать linked server

Кроме пути №1 - переписывание ядра на PL/SQL (код "Oracle migrate"),
есть еще путь с использованием линкованных серверов ("linked Oracle").
Суть linked Oracle в том, что создается linked server и view для всех таблиц, с которыми должен работать модуль в NEXUS. View нужны для того, что бы не писать в каждом запросе полное имя связанной таблицы сервер.БД.схема.таблица.
Разработка ведеться в привычной среде. В особо извращенных случаях возможно даже реализовать вызов связанных методов в виде sp на PL/SQL.
Сложости:
1. Все запросы надо писать в рамках SQL-92.
2. Учитывать, что все транзакции будут распределенные.
3. Синхронизация структур данных в Oracle и view в NEXUS.

Изображение пользователя st.

Я уже испробовал

Я уже испробовал в "Оптистоке". Там центральная БД - MS SQL 2005, питается из гетерогенных источников, например, из оракловых БД SAP R/3.
Запросы можно писать в полном соответствии синтаксиса оракла внутри openquery(), а вне его полный синтакси MS SQL. Например:

INSERT INTO sales(product_code, customer_code, qty, qty_date, sales_unit)
  SELECT product_code, customer_code, qty, qty_date, substring(sales_unit, 1, 3)
    FROM openquery(ORACLE_DATABASE,
      'SELECT Sum(BILL_QTY) as qty, 
          MATERIAL as product_code,
          "/BIC/CCUSTRC" AS customer_code,
          To_Date(CALMONTH, ''YYYYMM'') AS qty_date,
          BASE_UOM AS sales_unit
        FROM SAPR3."/BI/TBL_BI234"
        WHERE CALMONTH <> '' '' AND cast(BILL_QTY as integer) <> 0
        GROUP BY MATERIAL, "/BIC/CCUSTRC", To_Date(CALMONTH, ''YYYYMM''), BASE_UOM') as S
    WHERE datediff(month, qty_date, getdate()) <= 25;

А изменения

А изменения (update) таблиц в Оракл у тебя были?

Изображение пользователя st.

Не было

Только на чтение.
Насколько я знаю, INSERT/UPDATE/DELETE работают так
INSERT INTO OracleServer.Database.Schema.Table (field1, ...) ...

Там специфичного синтаксиса не требуется, в отличие от SELECT.

Безусловно интересна

Безусловно интересна спарка серверов в плане уменьшения затрат разработки. Но тогда оракловая БД будет существовать только в рамках пыльного хранилища данных. Хотелось бы, чтобы "код" (класс нексуса) и обработчики работали непосредственно над данными, лежащими в оракле без распределенной транзакции. Хотя MSSQL можно рассматривать как сервис или дистрибьютор к оракловой БД. Кто-нибудь прикидывал падение производительности такого решения как плата за простоту. М.б. оно просто ни в какие ворота не идет?

Изображение пользователя st.

Скоро

Скоро придется прикидывать, есть похожая задача. По итогам напишу.

Изображение пользователя ipanshin.

На самом деле

На самом деле
1. хотелось бы порвать эту пуповину Nexus-MS SQL, тогда и решение для Postgress появилось бы.
2.Потом существуют и обратные тулзы миграции на оракл типа omwb (oracle migration workbench). Для перевода ядра нексус, я думаю, применима. Для остальных классов можно написать а-ля CASP генератор на Csharp.

"порвать

"порвать пуповину" - это переход на 3-х звенку, т.е. нужно разрабатывать свой язык для написания БП (есть практически в каждой ERP :)
В автоматическиую миграцию кода sp с одного сервера на другой не верю. ИМХО, есть очень много вещей, которые оень трудно эффективно перенести на другую СУБД - установки окружения (форматы дат, системные переменные и т.д.), обработчики ошибок, работа с временными таблицами.
В принципе это все решаемые задачи, но код полученный в результате будет абсолютно не сопровождаем (ИМХО).