Migracion de Firebird a Oracle

[SCORDOBA]

Hola:

Tengo un proyecto en produccion con Firebird 1.5 y quiero migrarlo a Oracle. He bajado del la web de oracle el gestor 10g.

Mis dudas son:

Duda 1

¿Se pueden definir tipos extendidos para usarlos en la creacion de tablas (Los domains de interbase)?
Ejemplo:

create domain id integer not null;
create table clientes codigo id;

Duda 2
Firebird/INterbase tienen una cosa muy interesante, que es que un Store Procedure se puede abrir como un cursor que devuelva n lineas. En el codigo del procedimiento podemos poner la palabra clave "suspend" y el procedimiento devuelve una fila con los parametros de salida definidos en la clausula retruns, pudiendo usar el suspend todas las veces que sea necesario.

El resultado seria una View con la potencia de calculo que nos pueda dar el lenguaje PL/SQL.

Duda 3
Como se come oracle el tema de las dependencias con los Procedimientos, funciones, triggers.

¿Me deja borrar o modificar cosas que dependen de otras cosas?
¿Tengo que compilar las dependencias cuando modifico codigo con dependencias?

Bueno tengo muchas mas dudas, pero poco a poco.
Gracias

[jachguate]

Empezado por SCORDOBA

Duda 1

Básicamente No (al menos hasta la 9i). Normalmente trabajas con tipos de datos primarios.

Ya retorciendo las cosas, quizas podes crear un package de tipos, y usar los declarados alli. Nunca lo he hecho, y no me pareceria normal hacerlo, pero si queres probarlo, dejo en tus manos la idea.

Empezado por SCORDOBA

Duda 2

En oracle un stored procedure no devuelve un cursor. No en el sentido de interbase. Lo que si podes hacer, que no se puede en ib, es llamar a funciones almacenadas directamente en una sentencia select (por ejemplo en la de una vista).

También podes hacer una función (o procedimiento) que devuelva un ref-cursor.

Empezado por SCORDOBA

Duda 3

En lo personal me gusta mas que el de ib/fb. Regularmente te deja modificar cualquier cosa, y simplemente va inválidando los objetos que tienen dependencias. Esto te da mucha libertad para aplicar cambios a un esquema sin tener que eliminar primero objetos dependientes (por ejemplo, para cambiar un tipo de dato). Luego, cuando los triggers o sp's marcados como inválidos tratan de usarse, se compilan automáticamente primero, y si hay algun problema se reporta en ese momento.

Si queres evitar un reporte de error tan tardío, podes valerte del package standard utl_recomp para recompilar todos los objetos inválidos de un esquema (o incluso de la base de datos completa).

Hasta luego.