En este artículo, le diré cómo pensé seriamente en una alternativa a Oracle. ¿Pero qué hay de Postgre, dices? Sí, pero hay matices. Primero trataremos la pregunta "¿Por qué Oracle?"
Lógica empresarial en nuestra base de datos. En el libro de Oracle para profesionales, Tom Kite escribe
Cuando desarrollo aplicaciones de bases de datos, uso un mantra muy simple:
si es posible, hágalo con una sola instrucción SQL;
si esto no se puede hacer con una sola instrucción SQL, hágalo en PL / SQL;
si esto no se puede hacer en PL / SQL, intente usar un procedimiento almacenado de Java;
si esto no se puede hacer en Java, hágalo como un procedimiento externo en C;
Si esto no se puede implementar como un procedimiento externo en C, debe pensar seriamente por qué se hace esto ...
y en el diseño del sistema, sigo esta regla. Los tipos de objetos en Oracle son especialmente agradables; con su ayuda, la lógica empresarial compleja se implementa de manera hermosa y conveniente de acuerdo con todos los cánones de OOP.
Oracle es caro. Comprarlo y no usar todo lo que contiene será un error.
Y, sin embargo, siempre hay un factor de equipo y competencias. Si su equipo ha estado desarrollando todo en Oracle durante diez años, liberar Postgre puede ser doloroso.
Oracle es caro. Tan caro que puede escribir sobre eso varias veces, y no pensar en la necesidad de Oracle en un nuevo proyecto será un error.
Varias veces ya me encontré con publicaciones sobre el producto coreano Tibero, supuestamente creado para reemplazar a Oracle. Y ahora tienen una atracción de generosidad sin precedentes: las licencias estándar se distribuyen para los desarrolladores casi gratis, por un dólar por un enchufe. Entonces, entendemos: lo que los coreanos pueden ofrecer en este momento. Con los automóviles, después de todo, ¡ya (casi) tuvieron éxito!
Descripción del experimento
Los representantes de TMaxSoft dicen que Tibero es casi 100% compatible con Oracle, y que existe una utilidad para la migración de la base de datos. Decidí tomar mi base de productos, con lógica de negocios en Oracle, usando todo el encanto de OOP en PL \ SQL, y transferirla a Tibero. En esta publicación, no consideramos la migración de los datos en sí, es menos interesante y todavía no he intentado una migración completa.
La tarea es esta:
1. Tablas de transferencia.
2. Transferencia de índices, claves, etc.
3. Transfiera paquetes y disparadores.
4. Transferencia de tipos de objetos.
Pero primero, tratemos con las herramientas.
Las herramientas
Google sabe poco sobre Tibero. Descargamos la base de datos en forma de máquina virtual en la que ya se ha implementado todo. Solo hay dos herramientas: una utilidad para migrar T-UP y un IDE para DBA y el desarrollador tbAdmin. Todo se hace en Java, se ejecuta en cualquier lugar, en teoría.
T-UP se parece a esto:
Ventana principal: conexiones de bases de datos.
Si hace clic en Opciones, puede configurar algo.
Lo más importante, puede seleccionar los tipos de objetos para migrar.No se encontraron instrucciones, ayuda, consejos.
Da la impresión de una utilidad casera. A veces volaba con ejecuciones, pero básicamente trabajaba según fuera necesario.
La segunda herramienta es el IDE Tibero Admin. Se puede descargar desde el sitio web de TMaxSoft si se registra allí primero. También puede obtener una licencia de demostración allí.
Tibero Admin parece un viejo IDE típicoEstoy acostumbrado a la excelente herramienta de desarrollador PL / SQL de Allround Automations. En Tibero Admin, olvídate de las indicaciones contextuales, nada aparecerá en tu pantalla después de hacer clic en el "punto", no te agregará los nombres de tablas y objetos. Simplemente escriba el código, programadores. Ayuda, documentación? No Hay documentación en el DBMS en el sitio web del fabricante, tan interesante ... sin una búsqueda. No se encontró documentación para el IDE. Sin embargo, no hay nada complicado. Hubo problemas con la autorización: resultó que el usuario debe tener derechos de DBA para ingresar a tbAdmin. E interesante con los puertos
, 8630 es para SYS, para todos los otros 8629 .
Errores IDE. De vez en cuando, cuando tocas en algún lugar, el
índice de mensajes está
fuera de límites , un mensaje como
java.lang. Excepción: el compromiso exitoso es muy aterrador. Es necesario tener en cuenta los diferentes tipos de ventanas SQL y PSM: en la primera, es poco probable que compile el código del programa; en la segunda, no ejecutará la solicitud. Después de PL / SQL Developer: una apariencia miserable de una mano izquierda ...
Llegando al experimento.
Migración de tablas
Seleccionamos el esquema en T-UP, hacemos clic en Migrar, primero seleccionamos las "tablas" en las opciones y comienza el proceso de transferencia. Me encontré con dos problemas.
TABLAS ESPACIOS. Decidí transferirlos a tablas, pero Tibero parece haber tratado de reservarles tanto espacio como ocupan en la base de datos de origen. Y esto es mucho, y él no pudo. Creé los espacios de tabla manualmente, y luego todo salió bien.
Además de las tablas con valores de fecha POR DEFECTO del tipo '31 .12.2019 '. En la configuración de Oracle, tenemos este formato registrado, para Tibero ayuda
alter session set nls_date_format='DD.MM.YYYY';
pero no hay ningún lugar para que T-UP lo haga. Los colegas de TMaxSoft aconsejaron configurar la variable TB_NLS_DATE_FORMAT = "DD.MM.YYYY", pero no me ayudó personalmente. Tal vez hice algo mal. Tuve que crear tablas con tales parámetros manualmente, no hay muchos de ellos.
Resultado del primer paso: mover la estructura de la tabla de Oracle a Tibero funciona bien.
Claves e índices.
Seleccionamos las casillas de verificación ÍNDICE, RESTRICCIÓN en T-UP y reenviar. Surgieron problemas con CHECK debido a la misma situación con la fecha. En general, se han creado índices, claves primarias, verificaciones. Pero no pude encontrar claves foráneas en la base de datos recién creada. Y la migración de constantes termina en el registro T-UP con el mensaje
"Error de migración: java.lang.NullPointerException". ¿Coincidencia? No lo creo ...
Paquetes y disparadores.
En los disparadores no tengo nada complicado, fueron creados perfectamente. Es cierto que no verifiqué cómo funcionan, esta será una historia separada.
Hablemos de procedimientos y funciones que implementan parte de la lógica. Aquí, desafortunadamente, no todo salió a la perfección.
De una manera simple: en el
ejército de Tibero no hay una palabra
NUEVA . La construcción o: = NEW t_my_type () no se compilará. En Oracle, es cierto, no obligatorio, pero siempre escribí por alguna razón. Tuve que borrar.
El rol DBA permite que la ventana SQL acceda a todas las tablas. Sin embargo, al compilar un paquete o procedimiento en un esquema con dicho rol, al usar tablas y objetos de otro esquema, debe otorgar la concesión correspondiente al objeto. La magia del rol de DBA no ayuda aquí.
De lo específico. Obtuve un FORALL extraño en mi base de datos, que, sin embargo, funciona.
Tibero dice que
"la declaración dml debe tener un parámetro masivo ia para cerrar todo" . Y lo entiendo en el fondo, pero este código tuvo que rehacerse en un ciclo regular.
La situación con tablas que contienen objetos es peor.
CREATE OR REPLACE TYPE S1.TYPE_PAY_HIST AS OBJECT ( pay_status_id NUMBER(1), stamp DATE ); CREATE OR REPLACE TYPE S1.TABLE_PAY_HIST AS VARRAY(10) OF type_pay_hist; create table S2.RECEIPT ( receipt_id NUMBER(8) not null, pay_sum NUMBER(12,2) not null, receipt_hist S1.TABLE_PAY_HIST ); FUNCTION receipt_status_change(p_cmr_receipt_id NUMBER, p_new_status NUMBER) RETURN NUMBER AS l_receipt_hist s1.table_pay_hist; l_type_pay_hist s1.type_pay_hist; l_status NUMBER; BEGIN BEGIN SELECT receipt_hist INTO l_receipt_hist FROM receipt p WHERE p.receipt_id = p_cmr_receipt_id FOR UPDATE; EXCEPTION WHEN NO_DATA_FOUND THEN RETURN c_err_not_find_status; END; ... END;
Tenemos un error de compilación, escriba mistmatch.
Los chicos de TMaxSoft propusieron esta versión del código:
create or replace FUNCTION .... AS l_receipt_hist table_pay_hist; l_type_pay_hist type_pay_hist; l_status NUMBER; cmr_receipt_row cmr_receipt%rowtype; BEGIN BEGIN SELECT * INTO cmr_receipt_row FROM cmr_receipt p WHERE p.cmr_receipt_id = p_cmr_receipt_id FOR UPDATE; SELECT TYPE_PAY_HIST(r.pay_status_id,r.stamp) bulk collect INTO l_receipt_hist FROM cmr_receipt p,table(p.receipt_hist) r WHERE p.cmr_receipt_id = p_cmr_receipt_id; EXCEPTION WHEN NO_DATA_FOUND THEN dbms_output.put_line('NO_DATA_FOUND'); RETURN null;
El trabajo probablemente funciona. Pero no es tan conveniente, y tienes que rehacer el código.
El resto se compila normalmente, excepto por cosas específicas como SDO_GEOM. Y, por cierto, Tibero tiene un análogo. Sus manos aún no habían llegado a su estudio.
Tipos
En uno de los proyectos, usamos el poder de OOP de Oracle Hollow.
La pregunta más emocionante para Tibero fue sobre esto.
Creamos un cierto tipo, que es básico para un conjunto de otros tipos.
CREATE OR REPLACE TYPE t_tar_object AS OBJECT ( id NUMBER(12), smth NUMBER(12), CONSTRUCTOR FUNCTION t_tar_object RETURN SELF AS RESULT, MEMBER FUNCTION target(param IN NUMBER DEFAULT NULL) RETURN NUMBER, MEMBER FUNCTION inside(o t_tar_object) RETURN NUMBER, MEMBER FUNCTION clone RETURN t_tar_object ) NOT FINAL;
Y ahora estamos tratando de crear un heredero digno para él.
CREATE OR REPLACE TYPE t_tar_service UNDER t_tar_object ( is_virtual NUMBER(1), CONSTRUCTOR FUNCTION t_tar_service (p_serv_obj t_tar_object, p_main_id NUMBER, p_pack_id NUMBER) RETURN SELF AS RESULT, OVERRIDING MEMBER FUNCTION target(param IN NUMBER DEFAULT NULL) RETURN NUMBER, OVERRIDING MEMBER FUNCTION clone RETURN t_tar_object ) NOT FINAL;
El compilador se negará a anular la función de destino. Sin embargo, no hay preguntas sobre la función de clonación. Resultó que a Tibero no le gustaba ANULAR cuando el método tiene parámetros. De acuerdo, elimine la palabra ANULACIÓN. Pero esto es alarmante, y escribimos scripts de prueba. Hasta ahora con el tipo padre.
declare o1 t_tar_object; i1 number := 100; begin o1 := t_tar_object; o1.id := 1; i1 := o1.target;
Parece que no dejamos una opción al programa, no importa qué valor tome la variable i1, algo debería aparecer en la salida. Pero ... no aparece nada!
Inmediatamente recordé una gran películaEsta rareza no termina ahí. Empeorando el experimento
declare o1 t_tar_object; i1 number := 100; begin o1 := t_tar_object; o1.id := 1; i1 := o1.target;
Incluso el hecho de que después de todas las manipulaciones con los métodos del objeto, establecemos rígidamente el valor de la variable, no cambia nada: la salida está vacía.
Experimento de control, prueba tu locura:
declare o1 t_tar_object; i1 number ; begin o1 := t_tar_object; o1.id := 1;
El apreciado "grande" aparece en la salida. Espeluznante, ¿no es así? Usando un golpe científico, los chicos de TMaxSoft descubrieron que si eliminas el matiz "NO FINAL" de la especificación t_tar_object, entonces el objeto se comportará adecuadamente. Pero, ¿por qué entonces necesitamos tal ... sin herederos.
No tiene sentido hablar más sobre la POO en Tibero. Como, de hecho, la OOP en Tibero. Después de eso, surge otra pregunta: y el código de procedimientos y funciones que compiló, ¿funciona correctamente? Aún no lo sé Una gran cantidad de código ha emigrado y compilado. Para un proyecto que no contiene los tipos de ejercicios anteriores, este es un éxito definitivo. Pero probar la ejecución correcta del código es una tarea seria. Y para ser honesto, no esperaba encontrarme con ella. No estaré listo para decir si tendré un proyecto en este DBMS. Pero si lo hace, entonces el desarrollo se llevará a cabo en Oracle, utilizando herramientas convenientes normales y con una migración regular a Tibero. Escribir código en el IDE sin indicaciones contextuales y con errores periódicos de la interfaz en sí es un placer por debajo del promedio.
Conclusiones
¿Tibero tiene futuro en su estado actual? No estoy seguro Después de todo, si observa el costo de las licencias excluyendo megascale, entonces un socket estándar cuesta alrededor de 800,000, lo cual es más barato que Oracle, pero no a veces. Y como estaba convencido de mi propia experiencia, hasta ahora esto ni siquiera está cerca de Oracle.
¿Tiene sentido usar el Tibero casi gratis que se ofrece ahora? Quizás si. Dicen que al pagar el costo del soporte técnico (99,000 rublos por año para un zócalo), se permite usar esta base en proyectos comerciales. Si tiene un equipo de oracleistas disponibles, y necesita crear y colocar algo no demasiado complicado en su servidor, pero más barato y más rápido, una opción interesante. Todavía puede jugar la carta de sanciones, diciéndole a los clientes con problemas que Corea no es Estados Unidos.
¿Debo traducir proyectos existentes de Oracle a Tibero? De ninguna manera No hay razón para buscar tal aventura. Es más fácil renunciar al soporte técnico de Oracle y no pagarle nada a nadie.
¿Y si necesita crear una nueva instancia de un proyecto antiguo que se ejecuta en Oracle? Y como resultado, ¿comprar nuevas licencias? Piénsalo aquí. Es posible que su base migre y trabaje cualitativamente. Pero inmediatamente piense en apoyar dos áreas en el proyecto, o traduzca todo a Tibero. Consideramos los costos laborales, los riesgos y los beneficios de las licencias más baratas. Compara, decide.
Quizás en la próxima versión de Tibero todo será diferente. Solo es necesario terminar los tipos, hacer un IDE normal, tal vez cambiar la política de precios. Y si el DBMS es el mismo que el de los automóviles, entonces, después de 5 años, los coreanos pueden ocupar una participación de mercado significativa y suplantar el hegemón. Ya veremos.
PS
Una ventaja importante al elegir un DBMS para un nuevo proyecto puede ser el trabajo del soporte técnico de TMaxSoft. Ni siquiera compré una licencia por un dólar, y los muchachos me respondieron con prontitud, claramente interesados. Ayudaron tanto con preguntas estúpidas como con las descritas aquí. La retroalimentación es excelente.